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.
-
@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?
-
"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.marius (@[email protected])
@[email protected] in #FedBOX I use a list of IDs when sending an object as a reply. The list contains all ancestors of said object all the way to the initial grand parent. It makes it easier to generate trees out of the replies, but it's also maybe a misappropriation of the reply concept. :D @[email protected]
Metalhead.club (metalhead.club)
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.
-
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.
-
No worries. This is a microblog conversation, which means it's not a single conversation but a bunch of different people broadcasting to different audiences and everybody sees a different conversation tree. So it's easy to lose track of who's talking to whom and about what and that's pretty much exactly what I've been addressing.
-
@[email protected] Thanks for sharing this use-case, it's very helpful and quite novel, I might add!
An
inReplyToarray 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
inReplyToit might just terminate because it expects a single uri.
re: the original ask, specifically I was asking whether any other implementors specify
contextin anas:Note, resolvable to a Collection. -
@[email protected] 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...
