steve-bate / activitypub-mincore Goto Github PK

1. "id (MUST be valid for dereferencing)" ---> I'm not sure what this means. If this means what I think it means. I would prefer "MUST agree with the URL."
2. I would prefer if it was clearly stated that inbox is a POST endpoint. A similar URI = URL sentence is appropriate.
3. "Must support inbox Follow activity processing" -> There is no such thing. What there is processing for sending an Accept to a Follow activity and receiving one. Similarly for Undo.
4. " ActivityPub Minimal Core " -> A better name would include 'federation API', I know it's all people use from AP but it pays to be precise.

I've implemented an initial version of validation and extension with JSON Schema, but I think there are better ways to do it.

This could be interesting. In AP an Undo refers to an activity ID, which requires the activity (or at least the ID) to have been stored. In the Follow case, another option is to use the actor property to find the actor's inbox and remove that from any internal follower inbox data.

if your goal is to be compatible with most fedi impls, this is not enough. you specifically need to declare a type that is one of the five types in AS2 or else Mastodon/Pleroma/Misskey/etc will reject it

however: is that indeed the aim, or is the aim to be minimal activitypub? i would also like to make the point that extensions will almost certainly have multiple types, so this is something that ought to be considered at least on the consuming side, even if not for the single actor being produced. (per https://matrix.to/#/!uHqAjmOtrLtidOiczC:matrix.org/$LKdlBM3fEStSux5SDXFSwnGATPNtMLFssS99J2FB7q0?via=matrix.org&via=mozilla.org&via=beeper.com and related discussion above that point)

'minimal core' implies this is a subset of the requirements of AP/AS2 but it actually is a superset

This isn't a core, it's the opposite. It introduces more requirements.

e.g. extensions aside, this is a valid AS2 document or AP object:

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "type": ["Activity", "Object"],
  "summary": "Sally did something to a note",
  "actor": {
    "type": "Person",
    "name": "Sally"
  },
  "object": {
    "type": "Note",
    "name": "A Note"
  }
}

but because activitypub-mincore extends the requirement set to add a new requirement that type cannot be an array, it makes it invalid in activitypub-mincore.

I think it is misleading to represent this as minimal or and especially an 'activitypub core'. Just give it a new name like 'monomorphism' and say it's 'activitypub inspired' :P

This will be somewhat rambling, as it touches on a lot of issues in ActivityPub, which will need to be fixed for it to become FriendPub.

1. https://www.w3.org/TR/activitypub/#follow-activity-inbox describes something that I would call a delayed should. Nothing actually happens, but a task is enqueued for when either an Accept or Reject happens. Nothing actually happens on a Reject, except that the enqueued task is cancelled.
2. https://www.w3.org/TR/activitypub/#follow-activity-inbox actually describes something that belongs in Section 6 ... Client To Server. As the Accept of a Follow Request is an outgoing message.
3. https://www.w3.org/TR/activitypub/#follow-activity-inbox implies that a server and thus the human being behind it, should either Accept or Reject a Follow Request. I personally consider "ignoring" the Follow Request a perfectly valid human reaction. This is actually what happens if a server is Blocked. Thus the entire logic breaks down in an important Fediverse use case.
4. In summary https://www.w3.org/TR/activitypub/#follow-activity-inbox is not a good choice to implement.
5. On another note, speaking of a Follow Activity is bad. One should speak of a Follow Request. It is easy to imagine a Follow Invitation Activity ... I'm done commenting on the specification now.
6. We often talk about ActivityPub repairing the social web. One of the freedoms, we should emphasize is that if we don't want to talk to somebody, we don't need to talk to that person. One could talk this a freedom of association. It's important to start this stuff already at the minimal version.
7. In order to highlight this freedom of association, I would log an incoming follow request. Then provide a command to send the corresponding Accept (it's an outgoing message).
8. On another note: I think the correct action of receiving a Follow Request if the actor is already in the following collection is to automatically send an Accept activity. This will probably lead to the best eventual consistency. I haven't done an actual analysis here though. One would probably need to draw diagrams of what happens to following, followers collections in certain cases for this.