null

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