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.
-
What could it say instead?
It could give handling considerations with 429s.
It could specify needing to have an abandonment time after which point you assume an actor is "dead."
RFC 6120 (XMPP), when talking about clients, has the following requirement
-
@[email protected] There are two obvious interests at odds here:
- The desire to have content propagate as quickly as possible (which necessitates sending out activities as quickly as possible)
- The desire to not overwhelm a server (which would mean some form of a retry queue, potentially with exponential backoff)
I personally think guidance would be appreciated (i.e. abandonment time), but at the end of the day how an implementor handles it is their own business.
-
@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."
Instead you get things like these:
-
Jenniferplusplusreplied to Hrefna (DHC) on last edited by
@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?
-
Hrefna (DHC)replied to Jenniferplusplus on last edited by
@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.
-
@[email protected] @[email protected] well, that's because we're all building apps around a protocol whose largest implementor doesn't specify
context, ever.So you end up receiving disjoint objects whose only relation to other objects is
inReplyTo, and you have to hope you can find a match.That automatically precludes the ability to develop sync/backfill.
-
@julian @hrefna That might help, but it wouldn't solve anything on its own. 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.
There's so much stuff that's just not even considered. Not even at the level of "you should do authentication, somehow"
-
Genders: ♾️, 🟪⬛🟩; Soni L.replied to Hrefna (DHC) on last edited by
@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.
-
@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.
-
Hrefna (DHC)replied to Jenniferplusplus on last edited by
-
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 thatCollection(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...
-
There are protocol things that can be done as well:
S(a): I have something for you.
S(b): Not now. Try in x Minutes.Or
S(a): I have something for you.
S(b): Not now.
S(a) waits a term of their own choosing.
S(a): I have something for you.
S(b): Not now.
S(a): Let me know when you have a sec.
S(b) waiting until load subsides.
S(b): I am ready for you
S(a): I have something for you.
S(b): Thanks. -
@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.
-
@jenniferplusplus @hrefna I love this thread and the fact that you’re all thinking about these things. Not to muddy the waters, but...
This sounds a bit like FEP-5624 in that the original poster may want to to choose which parts of a thread to sync with others.
I think the original poster could be considered the primary source of truth, which might also minimize the amount of “gossip protocol” required to sync this distributed db.
-
-
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. -
@[email protected] do you know any other implementors who expose a collection (even if not defined by
context)? -
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. -
@[email protected] 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?
