It sucks that activitypub is so under specified.

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.

marius

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

@jenniferplusplus

marius

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

Jenniferplusplus

@mariusor the only specified behavior for receiving an activity on an object with an inteplyto value is to consider that value for inbox forwarding.

Jenniferplusplus

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

Does that mean Undo(Block(Undo)) is also valid? And (Block(Undo(Block(Undo)))?

@hrefna @jenniferplusplus @ivy