this person is working on a mac app specifically for #theforkiverse #fedidev
Technical Discussion
1
Posts
1
Posters
0
Views
-
RE: https://theforkiverse.com/@klemens/115915313316598172
this person is working on a mac app specifically for #theforkiverse
#fedidev
Gli ultimi otto messaggi ricevuti dalla Federazione
-
@julian well, sure, with a monolithic implementation, the client and the outbox and the delivery agent are all the same app. but they don't have to be. the model is that the client submits to the outbox, and the outbox could also talk to a separate delivery agent internally. it's all opaque from outside the outbox. your internal "outbox" is the code that serializes activities and sends them to the delivery workers.
-
@trwnh@mastodon.social said in Expanding collections on delivery:
> say you are an outbox and you get an activity to: some id. you deref the id and get some info. what do you do?Simple. My outboxes send a "not supported" HTTP tag 🤣
But I'm being facetious.
From a C2S standpoint I suppose that makes sense. Thanks.
-
@julian now remove the requirement. what do you do instead?
- if it has ldp:inbox, send an LDN
...and that's it. at no point were you ever told or required to do anything else, so your followers/audience/members/etc will never get the activity even if addressed, because the collection was never expanded.
-
@julian i don't think it's "inferred", and leaving ambiguous cases up to inference in specification is typically called "unspecified behavior" ;)
say you are an outbox and you get an activity to: some id. you deref the id and get some info. what do you do?
- in all cases, if it has an `inbox`, you send an LDN to that id if you can.
- in case it's an as:Collection, you iterate over its items in theory and repeat step 1 recursively. (this is also problematic because it can be both paged+unpaged)
-
@trwnh@mastodon.social so collection expansion is mainly for when I am sending an activity to collections that I control?
Then I'm wondering why this needs to be explicitly spelled out and required because it seems to be inferred already from a UX perspective.
-
@julian there's probably a bunch of open issues on the https://github.com/w3c/activitypub/issues tracker regarding the problems with outbox delivery. those problems might be addressable all together, but it might instead make more sense to conceive of a sort of "LDN proxy" which handles deliveries instead (and holds your keys as an HTTP agent sending signed messages)
-
i would be fine with removing this collection expansion behavior from outbox delivery if it was decided that outbox delivery itself is problematic and should be removed -- probably in favor of the client being responsible for sending notifications, where the client can apply whatever logic it wants.
this is kinda what mastodon does right now as a monolith -- it is both the activitypub client (submitting to its internal outbox) and also the http agent for linked data notifications.
-
> 7.1.2
wrt inbox forwarding, this only helps when addressing collections of *someone else*, where the contents are private. for your own collections, unless you plan to deliver all such activities to yourself with the expectation that you will forward them (why didn't the outbox do it for you?^1), it doesn't help you.
^1: if the outbox doesn't have your credentials, then it can't do this. in this case, you or your client is responsible for deliveries, and the outbox only publishes.
