FEP-49eb: Batched Inbox Delivery
-
RE: https://aus.social/@maddyunderstars/117127750677454333
FEP-49eb: Batched Inbox Delivery
I've wanted batched inboxes for a while, and so here's a FEP for how you might do that.
My big problems with this currently are:
- The `object` of the `Add` is a `Collection`, which would usually mean to add the collection obviously, but here we add the collection's items. It's like this because we need to add some metadata such as start time and ordering, and we can't edit the activities themselves because then the proofs fail when those extra properties are removed when forwarding to other servers. Further, editing the activities might lead to conflicts, and using a prefixed prop like 'fep-49eb:ordering` just leaks that batching was used if forwarding was to happen without removal
- The capability discovery here is annoying I think. I didn't want to add a new `batched` inbox property on actors because then it's completely incompatible with multibox, and I want multibox to remain optional here too.https://codeberg.org/MaddyUnderStars/fep/src/branch/feat/fep-49eb/fep/49eb/fep-49eb.md
-
RE: https://aus.social/@maddyunderstars/117127750677454333
FEP-49eb: Batched Inbox Delivery
I've wanted batched inboxes for a while, and so here's a FEP for how you might do that.
My big problems with this currently are:
- The `object` of the `Add` is a `Collection`, which would usually mean to add the collection obviously, but here we add the collection's items. It's like this because we need to add some metadata such as start time and ordering, and we can't edit the activities themselves because then the proofs fail when those extra properties are removed when forwarding to other servers. Further, editing the activities might lead to conflicts, and using a prefixed prop like 'fep-49eb:ordering` just leaks that batching was used if forwarding was to happen without removal
- The capability discovery here is annoying I think. I didn't want to add a new `batched` inbox property on actors because then it's completely incompatible with multibox, and I want multibox to remain optional here too.https://codeberg.org/MaddyUnderStars/fep/src/branch/feat/fep-49eb/fep/49eb/fep-49eb.md
-
@rimu Thanks. Since FEP-1a11 documents PieFed behaviour and only addresses Likes/Dislikes/Undo in FEP-1b12 Groups, I figured a new FEP would be useful. This one is for any activity to any actor(s)
-
@rimu Thanks. Since FEP-1a11 documents PieFed behaviour and only addresses Likes/Dislikes/Undo in FEP-1b12 Groups, I figured a new FEP would be useful. This one is for any activity to any actor(s)
Cool. Yep.
-
? [[global:guest]] crossposted this topic to General Discussion
-
RE: https://aus.social/@maddyunderstars/117127750677454333
FEP-49eb: Batched Inbox Delivery
I've wanted batched inboxes for a while, and so here's a FEP for how you might do that.
My big problems with this currently are:
- The `object` of the `Add` is a `Collection`, which would usually mean to add the collection obviously, but here we add the collection's items. It's like this because we need to add some metadata such as start time and ordering, and we can't edit the activities themselves because then the proofs fail when those extra properties are removed when forwarding to other servers. Further, editing the activities might lead to conflicts, and using a prefixed prop like 'fep-49eb:ordering` just leaks that batching was used if forwarding was to happen without removal
- The capability discovery here is annoying I think. I didn't want to add a new `batched` inbox property on actors because then it's completely incompatible with multibox, and I want multibox to remain optional here too.https://codeberg.org/MaddyUnderStars/fep/src/branch/feat/fep-49eb/fep/49eb/fep-49eb.md
The
objectof theAddis aCollection, which would usually mean to add the collection obviouslyYou can introduce a new activity type, which will have different semantics.
e.g.
DeliverBatch-----
startTime: The creation time of the chronologically first activity in this batch.
I suggest clarifying what "creation time" means. Is it the value of the
publishedproperty of an activity?Delivery
The
Addactivity in the example does not have theid,actorandtoproperties, which are usually required.Processing
Should receiving servers add
Addactivities to inbox collections? -
The
objectof theAddis aCollection, which would usually mean to add the collection obviouslyYou can introduce a new activity type, which will have different semantics.
e.g.
DeliverBatch-----
startTime: The creation time of the chronologically first activity in this batch.
I suggest clarifying what "creation time" means. Is it the value of the
publishedproperty of an activity?Delivery
The
Addactivity in the example does not have theid,actorandtoproperties, which are usually required.Processing
Should receiving servers add
Addactivities to inbox collections?@silverpill @technical-discussion I would like a new activity type, but I wanted it to be compatible with multibox which uses Add. Although it doesn't allow for collections as their objects, so maybe a custom type is fine...?
I left `id`, `actor`, and `to` out because multibox also omits them. Additionally, batches don't have much use outside their POST request, so giving them a resolvable ID isn't super useful, and deduplication can be done per activity instead. Since the activities could be addressed to anyone and be created by anyone, `to` and `actor` dont have singular values either. Although I do realise now that omitting `actor` makes it incompatible with FEP-2277...
Good point on startTime/endTime. I'll clarify that tomorrow.
No, receiving servers should not add `Add` activities to their inboxes.
-
@silverpill @technical-discussion I would like a new activity type, but I wanted it to be compatible with multibox which uses Add. Although it doesn't allow for collections as their objects, so maybe a custom type is fine...?
I left `id`, `actor`, and `to` out because multibox also omits them. Additionally, batches don't have much use outside their POST request, so giving them a resolvable ID isn't super useful, and deduplication can be done per activity instead. Since the activities could be addressed to anyone and be created by anyone, `to` and `actor` dont have singular values either. Although I do realise now that omitting `actor` makes it incompatible with FEP-2277...
Good point on startTime/endTime. I'll clarify that tomorrow.
No, receiving servers should not add `Add` activities to their inboxes.
@maddyunderstars An activity without
idandactorcan't be authenticated:- The receiving server can't use the HTTP signature because it can't check
Key.owner == Activity.actorwhen there is noactor.
- The receiving server can't verify activity by fetching it from the origin, because there is noidMaybe this batch-
Addactivity is a special activity that differs from all other activities and should be unwrapped without authentication? In my opinion, the case for such "special activity" is not sufficiently strong.
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login