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.
-
@[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?
-
"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.
