It sucks that activitypub is so under specified.

Dana Fried

Yeah, I totally get the idea of "let's create a framework that lets people create their own ontologies and share information using them". Unfortunately, by being totally unopinionated about any of those ontologies you create a situation in which you have not actually created a standard, but rather a platform on which competing, subtly- (or grossly-) incompatible standards can fight, forever.

Jenniferplusplus

Anyone who think that I'm picking at flaws around the edges of activitypub should feel free to tell me how one is supposed to ask permission to reply to someone else's post. What message do you send? Where do you send it? How will you know if permission was granted? How will you know the recipient even understood the request? How will other people know the reply exists? How will they know it was permitted?

Jenniferplusplus

ATProto has answers to these questions. I don't particularly like most of those answers, but they exist. I would know how to implement it. I would know how to make it function at scale. I would know how to make it function with 3rd parties. I would know how to set expectations. I could reason about what's possible and recover from errors and disruptions.

None of that is true of activitypub.

I'm trying to help fix that. You can't do that without acknowledging the situation.

Ivy [_gay] Mae :fire_trans:

@jenniferplusplus I'm currently implimenting activitypub and its a rancid mess. honestly my biggest gripe with the protocol is the undo activity. the fact that an undo can be issued for an undo is the most ridiculous and downright idiotic thing ever because that means you can't just delete things and be done with it. you need to store the undone activity and the undo in case the activity gets undid :zerotwo_big_angry:

Jenniferplusplus

@ivy I think I blocked out undo

Ivy [_gay] Mae :fire_trans:

@jenniferplusplus blocked out as in you don't handle it or blocked out as in you have the code blocked out ie like put together?

Jenniferplusplus

@ivy blocked out as in my mind just refuses to retain knowledge of the undo activity whenever I'm not actively looking at it

Hrefna (DHC)

@jenniferplusplus "I don't like these answers, but at least they exist" is a _thing_.

It may not solve the problem I want to solve, I may dislike it for other reasons, but at least I can unambiguously implement it and be able to talk to others who are okay with the tradeoffs being made there.

Hrefna (DHC)

@jenniferplusplus

I regret to say that Block(Undo) is, in fact, a valid operation.

…I'm going to go back to my dark corner now.

@ivy

smallcircles (Humanity Now 🕊)

@jenniferplusplus in light of the effort I'm very curious how you think about object capabilities. And specifically thinking of @cwebber and @spritelyinst here posing a very exciting vision for the fedi.

In the original #Spritely Project the mission was that "if your social network supports a #Fantasary then you can do anything", unlocking full potential of the technology base.

Rekindling that vision may be a great rallying call for folks to collaborate on something really transformative.

smallcircles (Humanity Now 🕊)

@jenniferplusplus @cwebber @spritelyinst

Here is the old #Spritely #Fantasary project page:

Spritely

(spritelyproject.org)

marius

> how one is supposed to ask permission to reply to someone else's post.

@jenniferplusplus I think about this problem the other way around.

If someone does not have permission to reply to my thing, my server will reject the activity that does so, or my client will remove the reply from the reply collection.

Jenniferplusplus

@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

marius

@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.

Jenniferplusplus

@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.

marius

@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

Jenniferplusplus

@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?

marius

@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.

Helge

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.

Jenniferplusplus

@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.