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
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?
@julian But that could be specified at the protocol level. It isn't, but it is kind of weird
There are entire sections on it for Dynamo (first image), Tiara discusses it extensively in the posted snippet (second image) and in multiple other sections, and it is covered as something to address in Requirements for Signaling Protocols (RFC 3726).
These all have multiple sections addressing different parts of this problem and solve it with different levels of flexibility, but they all address it.
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...
Yeah I've had a number of times where I wanted to query a collection - but hopefully something a bit more lightweight than a full blown query language.
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.
Most everybody uses followers, following and outbox in some form. We also use them for Access Lists (aka circles/aspects) and photo albums and search results. I'll probably use them for event calendars soon. 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.
Everybody has lists of all kinds of things on their server, but turning them into collections means you can share them.
@mikedev 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?
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.
That's fine for what you're doing, but we don't have a reply 'tree'. We have a conversation which is an object owned by its creator. They add and remove activities from it. If it wasn't added to the conversation collection, it's not part of the official conversation and supporting applications will ignore it. In this way we co-exist with microblogs, but we can do lots of things that they can't. Like hold a coherent conversation with a defined audience, and support circles/aspects and private groups, and have comment controls. And we can relay things without third party permission artifacts. And we aren't wasting time talking to people that never see us and don't even know we're in the conversation. it's actually a pretty clever construct.
@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 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.
@hrefna What needs to be specified at the protocol level?
If I received a 429 I'd naturally assume that I should put the request back in the queue for retry, but I can see how other implementations might not support that.
@julian It Depends™, but even just saying something like:
"A receiving server MAY return a 429 on a request. If this happens or if the server cannot be reached the sending server SHOULD retry with exponential backoff. They SHOULD have a period of time after which they will stop trying and SHOULD have a period of time after which they will consider the actor 'dead' and stop sending them messages."
Add comment