great read! you’re spot on in a lot of things, but i had a few nitpicks

bengo wrote:

In ActivityPub, Data Portability comes largely from the Social Data Syntax, not the network protocols.

The data syntax and semantics enables, amongst other things, data portability and a good federation protocol.

But various endeavors above are trying to solve data portability primarily via network protocols. I’ve been wondering whether that’s the right layer on which to tackle this challenge? Or if some enhancement at the data syntax layer might help.

the data syntax is mostly fine, actually. the challenge for data portability is not in copying documents from one location to another; it’s in being able to refer to them independently of network location, as you touch on later. links are what define the network. the data is already “portable”, it’s just that if you port the data, then you destroy the existing network of links.

bengo wrote:

a hard choice to make for 5 years now: do you build for ActivityPub’s protocol, or do you build for the Mastodon Protocol? The former is fairly well-specified, has consensus-driven governance via W3C / FEPs, but is not implemented by Mastodon. The latter has all the end-users.

i actually think the “activitypub protocol” is not “fairly well-specified”. it’s not that mastodon simply has all the users. it’s that mastodon implements its own protocol on top of activitypub (or LDN). the only S2S protocols that activitypub actually defines are:

• delivery (LDN where the payload is an Activity)
• following (send a Follow, get back an Accept Follow or Reject Follow, you can Undo Follow – but note that removing a follower is undefined!)
• liking (send a Like, it gets added to the likes collection on that object, also it gets added to your liked collection on your actor)
• sharing (send an Announce, it gets added to the shares collection on that object)

the other activities mostly don’t have any side effects within activitypub. for example, Create has “surprisingly few side effects” in S2S AP, but in the Mastodon Protocol it actually has significant side effects, in that it persists a “status” in the remote database, and the shape of that activity has a lot of additional requirements placed on top of it. these are all things that are left undefined by AP, and i don’t think it is AP’s responsibility to define those things, but an additional protocol layered on top of AP should definitely do that. and this is de facto the Mastodon Protocol unless some other entity defines a different protocol (e.g. the Lemmy Protocol)

these are actually really important things to define, and the fact that they’re not defined is the biggest problem with the “fediverse” as a network. if you want to interoperate with anyone, you need to basically read their documentation and probably their codebase too and possibly reverse-engineer stuff as well and discuss with other people who did the same. all behavior is formally undefined, or more appropriately implicitly defined by the codebases. it’s never stated anywhere that things like deleting your actor have additional side effects like possibly deleting all your “statuses” in that remote database.

bengo wrote:

When followed, the link to the input of the ActivityPubOutboxPostProcess would be the exact request body of the HTTP Post request sent by the client to the outbox server, and would include any DataIntegrityProof created by the client.

i don’t think it makes sense to store the HTTP POST request unmodified unless you’re interested in doing anything with it later e.g. validating an HTTP Signature…

bengo wrote:

The more concerning part of what Mastodon has normalized is that the Mastodon Server generates keypairs, not the end-user that is the true entity that the social objects are attributedTo.

one thing i’ve toyed with is the possibility of linking an object to the Create activity that led to its creation. i was going to use attributedTo for this.

bengo wrote:

servers should really let an end-user that the Actor represents bring their own verification methods, and only share the public keys with the ActivityPub Server.

the server can lie about public keys attached to the actor though. what we probably need is to instead signal which clients are attached to any given actor, and then allow clients to declare their own keys. this is because the clients are the user-agents that are acting on behalf of the user, and it is generally not the user who should be handling their own keys directly.

bengo wrote:

There’s no reason an ActivityPub server should demand to control the end-user’s private keys.

one reason is that an actor needs something to prove its own identity when making network requests. the client can use the proxyUrl endpoint to fetch objects as the actor, and so the actor needs its own key for federated identity… or so goes the argument.

bengo wrote:

I think a lot of people want ‘Account Portability’ because what they really want is Single Sign On.

disagree; SSO is nice to have but you should be able to port your identity just like you should be able to port your data.