null

Helge

First observation: This is an important MUST requirement. A Fediverse application should never explicitly tell users that they have been blocked (and thus unblocked).

Second: This is usually trivial to implement. Software like Mastodon only shows a very limited set of Activities. This means you miss all my AnimalSound activities saying mooo, but you also don't need to worry about seeing a Block or Unblock activity.

Helge

ActivityPub C2S being a stub doesn't tell you how to implement this. Even if it is super relevant if you want to grant people access to the full inbox.

So let's discuss what you have to do to implement not adding Undo Block to the inbox:

Case 1: The block is embedded without an id. Well you can then just check it's an Undo activity. Look at the embedded Activity and then check if it's a Block. There's some more awkwardness with type being possibly an array.

Case 2: The block is not embedded, this means that you have to look up the Block in your database. If it is there, you get to not forward the activity.

Helge

Now to Case 2b. You get an Undo with an id that is not in your database. What should you do?

Option 1: You forward it. This might inform a smart user of the existence of the Block or something he should not be aware of.

Option 2: You look up this id! And then only forward the Undo activity if the resolved activity is not a Block activity.

This means in general that an Undo with an id as object is only forwarded if the id is resolvable. Not sure if this is the behavior, I want. I said that ActivityPub is a stub before, let me say it again. A non stub specification would address this.

Helge

Now, to turn around again. If there was an Unblock activity. The entire thing would be trivial. Check the type, be done.

No database queries. No requests to other domains. No nothing. Just a simple string comparison.

So you know now what I would expect from ActivityPub 2.0: Get rid of all this nonsense that requires complicated logic, and allow us for simple implementations.

marius

@helge you should think of Block activities as being local. They don't make much sense in the wider server to server ActivityPub ecosystem because there's no way to enforce remote servers acting on them.

So, you as a user sends a block activity to your server for another ActivityPub object. The only thing that needs to happen is that when your server receives activities from that object that are somehow addressed to you, it doesn't do a thing. That's all. It does not matter how the server keeps track of this information, and therefore Undo on the Block makes the most sense (to me).

marius

@helge *by "doesn't do a thing" I mean, it does not add them to your inbox (and/or other relevant collections)

silverpill

@helge Another solution is partial representation:

{
  "type": "Undo",
  "id": "https://social.example/activities/undo",
  "object": {
    "type": "Block",
    "id": "https://social.example/activities/block",
    "partial": true
  }
}

Then there is no need to register a new type for every possible "undo" action.

Partially embedded objects

Sometimes object is not embedded fully and only a few of its properties are included. One example of this practice can be found in FEP-400e which requires objects on a wall to have a target property that contains an “abb…

SocialHub (socialhub.activitypub.rocks)

Helge

I've written up here and here, why one needs to deliver the Block activity. So thinking of them as server local is wrong.

If a server does not respect Block activities, I believe that a server block is justified.

marius

@helge besides the fact that you seem to be bastardizing the FEP mechanism into your own fanfiction storage for cow related content, I repeat - and at a first glance you don't seem to treat this case in any of your texts - there is no way to make other servers actually implement and obey Blocks, so there's little point in disseminating them remotely.

Obviously you should still do that, in the hope of a better fediverse, but you'd be a fool to rely on that working in all cases and for all servers.

marius

@helge Oh, I'm mistaken, you do treat the case where other servers don't handle Blocks:

> This means one needs servers to react to blocks in a strictly specified way. If they don't, your protocol does not behave as it should, and thus is a failure.

This is a very naive perspective in my opinion. We either work with what we have, or just give up. There are two kinds of protocols: the ones that people complain about and the ones that nobody uses, to paraphrase Stroustrup.

Jenniferplusplus

@mariusor @helge
Working with what we have can and should include trying to make improvements to it.

Helge

This would be perfectly fine with me. One would just need to specify that this mechanism should be used, and that undos with just an URI as object are illegal.

Migrating towards this would take time. Also alone investigating how well the partial embed form is currently supported would be quite complicated. I think one might be able to test it for Follow activities. Block activities get only really interesting once 3 or more actors are involved and setting up such a test environment would be hard.

I created this issue that would be the first step towards doing this.

silverpill

@helge We could start with a FEP and then gradually move towards ActivityPub 2.0 where type hints will be mandatory.

Besides Undo, embedded partial representation of object would simplify processing of Accept/Reject - see this issue: https://github.com/superseriousbusiness/gotosocial/issues/3460

Also, embedded partial target in Add/Remove