Recent searches
Search options
Part of my frustration with #ActivityPub and one of the things I find baffling giving everything else in it: the lack of tools for backpressure.
Backpressure is fundamental in building reliable distributed systems (c.f., Notes on Distributed Systems for Young Bloods). From a C2S perspective I get why it wouldn't need to be specified, but from a S2S _federated_ protocol perspective its absence is frustrating.
All that it says is to take care not to overwhelm _others_ and a bit on rate limits
@hrefna yes.
But I also want state convergence. No matter what, different hosts are going to wind up with different views of the state of the graph. Why are there no mechanisms to detect that and enable convergence?
@jenniferplusplus Yes. Yes. A million times yes.
There's no _sync_ capability despite that we're basically building a distributed database where we are trying to have a sync'd state.
So if you fall off for a few hours what is expected to happen?
Everyone's favorite thing from C++: Unspecified.
, 
; Soni L. @hrefna @jenniferplusplus the more y'all talk about AP the more we want to stay away from it heh.
if it's worth anything: thanks for that.
@jenniferplusplus@hachyderm.io:
I want a mechanism to determine if two party's view of a collection are equivalent. I want to be able to query if an object is contained in a collection without enumerating the whole collection. I want a mechanism to request re-delivery or maybe failed delivery notifications.
For what it's worth, these are all goals that would align well with the interests of a broad set of implementors. I make a little noise now and again about the SWICG forum task force, but directly addressing some of these concerns would definitely be on our radar.
Current focus is on aligning on a common object type for higher level collections (the context), but I'm thinking that Collection (ordered, ideally) would be the best fit and also allow for future use cases like you mentioned earlier.
You have the ideas, we might be able to supply the coordination...
@julian
Yeah, I've been trying to keep up with it. I've generally stepped back from the swicg lately, although you seem to have the most functional wing of that org. I've imagined reengaging in the future, when I can lead with an implementation. Otherwise it's just more theorycrafting, and there's too much of that already.
If maintainers of real implementations in the forasphere are soliciting input, that might be another story.
And in the Nomad protocol, we've got delivery notifications. It's critical to finding out what happened to something in a decentralised communication system. It's 2024. Vanishing into space without any trace is not an option.
@mikedev@fediversity.site do you know any other implementors who expose a collection (even if not defined by context)?
Everybody has lists of all kinds of things on their server, but turning them into collections means you can share them.
@mikedev@fediversity.site said in Part of my frustration with #ActivityPub and one of the things I find baffling giving everything else in it: the lack of tools for backpressure.:
And of course as mentioned we use them for conversations so that everybody sees the same view of the discussion. It's a very under-utilised organisational mechanism and that seems odd. They're quite useful.
Ah yes, that was what I was referring to, a collection for a conversation. It certainly does seem under-utilised but I wasn't entirely sure whether that was true or not.
Are you aware of any other implementors that expose a collection for a collection of a topic's content?
"Are you aware of any other implementors that expose a collection for a collection of a topic's content?"
Not currently.
@julian @mikedev
Fedbox does, and they use the Replies collection for it.
https://metalhead.club/@mariusor/111716353263015161
Letterbook will. I'm flexible as to how, but my current plan is to duplicate the OP's replies collection into the context.
cc @mariusor
I'm not sure if this is what @julian asks about, but this would be an example of what I meant in the post mentioned by @jenniferplusplus:
https://federated.id/objects/2e6cf5a8-ffa8-4fca-b4cd-8e0c9a584a75/replies
You can see the list of replies fully (the public ones at least), and some of them have inReplyTo attributes that reference multiple objects. This is done to have a way to reconstitute the reply tree structure.
@mikedev I wasn't following the larger discussion thread, I don't really know what you guys are talking about. I only meant my reply as a clarification to the quote Jennifer++ posted.
@mariusor@metalhead.club Thanks for sharing this use-case, it's very helpful and quite novel, I might add!
An inReplyTo array addresses the problem of backfill/ghost-replies with a bottom-up approach, vs a context collection which would be a top-down approach... though depending on what direction your tree grows, perhaps it's the other way around
A context collection would also provides the entire tree, which depending on size may or may not be preferred. Tradeoffs...
I think perhaps there is space for both, although I will admit that if my code encountered an Array in inReplyTo it might just terminate because it expects a single uri.
re: the original ask, specifically I was asking whether any other implementors specify context in an as:Note, resolvable to a Collection.
> ...if my code encountered an Array in inReplyTo it might just terminate because it expects a single uri
@julian sadly that's the case for most fediverse software at the moment. :(
@jenniferplusplus@hachyderm.io said:
Letterbook will. I'm flexible as to how, but my current plan is to duplicate the OP's replies collection into the context.
Good to know, I'll add your potential implementation into the table I'm creating... at present I'd want to know the current or potential usages of context. Hopefully there won't be too many disparate and incompatible implementations to reckon with...