It sucks that activitypub is so under specified.
-
@mariusor the questions still remain. How will anyone know if they have permission? How will third parties know if someone else had permission? How would they send the reply? Where do they send it? How would they discover other replies?
None of this is specified
-
mariusreplied to Jenniferplusplus last edited by [email protected]
@jenniferplusplus I guess you're right, but in my opinion you're overcomplicating things.
I don't think that a distributed permission system would make the system better.
The canonical representation of the reply collection of an item is what you get when you query that item's reply collection IRI. That's it. What's in there is the "truth".
IMHO nobody needs to "know" if a remote server can add things to it, because the mechanism through which this happens is not governed by anything else but the server where the collection is hosted.
-
@mariusor there's not even a specified mechanism for trying to add things to that collection. How does someone reply to something? What is the actual process for doing that?
This is supposed to be a communication protocol. Replying to something is the most basic communication there is, and the protocol has nothing to say about it.
-
@jenniferplusplus erm.
The replies collection[1] present on Objects contains (what to me looks like) enough information for establishing the relationship between a received Object's inReplyTo property and the replies collection itself.
Is that too little information for your needs? What else do you require?
[1] https://www.w3.org/TR/activitystreams-vocabulary/#dfn-replies
-
@mariusor i can read the vocabulary. It doesn't describe any behavior. What is the actual message that would cause a new reply from a second party to appear in the original object's replies collection? Where should that message be sent? How would anyone else know it happened and was accepted?
-
@jenniferplusplus sorry to be an ass about this, but it feels like you're not cooking with your heart.
It's not spelled out for us but it's clear from reading the spec(s) that the message needs to be "sent" from the server where the reply comes from to the server where the original is. Therefore the client of the reply guy actor needs to add the original's attributedTo actor to the list of recipients if it wasn't already there.
Anyone else would know it happened if they were also in the recipients list, or when their client retrieves the replies collection of the original.
-
Just sliding in here, as I consider having a proper replies specification important and the way ActivityPub handles it: Just plain wrong.
Having a proper replies specification is important due to: Well it's a hard problem, and popular implementations like Mastodon handle replies in a way that is IMO wrong. What is wrong with Mastodon's replies, you ask? Take your reply. It is addressed to
"cc": [ "https://metalhead.club/users/mariusor/followers", "https://hachyderm.io/users/jenniferplusplus" ],whereas Jennifer's are addressed to her own follower's collection. A correct behavior would be all posts addressed to Jennifer's followers collection. Not this alternating stuff.
So if AP was a proper spec, I could open a bug ticket against Mastodon. Currently, it's just my opinion. I would even go so far as Mastodon having quote-toots faking being replies due to this behavior.
-
@mariusor this is supposed to be a formal technical specification for a communication protocol. I shouldn't have to guess. I shouldn't even be able to guess. "Cooking with your heart" is fine for recipes, not computers. That's how we wound up with a dozen mostly incompatible implementations. That's why we can't move forward on harmonizing those incompatibilities.
-
@helge addressing is up to the client. In my opinion there's no "wrong" way to do it. The authors of the Activities should be the ultimate arbiters of whom receives it. The fact that Mastodon (and most of the clients) in the fediverse hide this option is the *actual* problem in my opinion.
-
mariusreplied to Jenniferplusplus last edited by [email protected]
@jenniferplusplus there's no formal specification for activities addressing because, like I replied to Helge, it's up to the author and their client to determine whom it gets delivered to.
That's why the specification tells us about what happens when receiving objects/activities with inReplyTo populated, but not how one finds where to send them.
To me it makes perfect sense, but I'll grant you that I might be missing things.
-
Jenniferplusplusreplied to marius last edited by [email protected]
@mariusor the only specified behavior for receiving an activity on an object with an inteplyto value is to consider that value for inbox forwarding.
-
@helge @mariusor I'm not actually sure I agree that's how it *should* work. But my point is that it shouldn't even be possible to have this disagreement. The specification should specify these things. We could then like it, or not. We could use it, or not. But we couldn't argue about whether something is good, or correct, or valid. Not for such huge and fundamental parts of the spec. The time for that was while the spec was being written.
-
The Nexus of Privacyreplied to Hrefna (DHC) last edited by
Does that mean Undo(Block(Undo)) is also valid? And (Block(Undo(Block(Undo)))?
-
Jenniferplusplusreplied to The Nexus of Privacy last edited by
@thenexusofprivacy @hrefna @ivy it's very difficult to produce an invalid AP document. It's a little more interesting to discuss whether it's meaningful or legible, but that's a matter of convention, not specification.
