Changeable usernames?

[SorteKanin]

@trwnh

in ActivityPub, you do not follow servers, and servers do not perform activities. servers merely host actors as HTTP resources in the default interpretation, and provide interfaces for communicating with the actor inside its cage (outbox, proxyUrl, and so on).

what you may be referring to is that in “the fediverse”, applications follow the instance model. this is evident by the overwhelming use of sharedInbox and the social-platform-as-a-service approach taken by most implementations.

I have a really hard time taking this very “spec-oriented” actor-first approach seriously - you’re phrasing it as though the whole fediverse is misusing the standard and that the instance model is wrong or at least not the primary way the standard should be used.

But this rings very hollow when there are no significant implementations in existence (afaik) that take the supposedly “correct” actor-first, “instance-less” approach.

If the standard is constantly being misused because it is impossible to actually use it in the intended way, then it is the standard that is wrong, not the implementations. This idea of an actor-first/instance-less approach is all but a hypothetical fantasy until someone actually creates a realistic, viable, generally usable implementation with that approach.

@trwnh

take it one step further, and you find that federation doesn’t make sense anymore; what you would really want is syndication instead between different sites. the messages are discarded and the content is made available on remote sites as a “post” in the database.

Maybe this would be a simpler approach to achieve the same thing as what we have today? If we ever get an ActivityPub 2.0 or a spiritual successor, maybe we should consider aligning the standard more towards this approach.

[trwnh]

@SorteKanin

you’re phrasing it as though

I’m not sure how you got this out of what I wrote, but the part you quoted was intended to disprove the idea that “ActivityPub describes a network of servers”, because it very clearly isn’t true – Alice Follows Bob, mastodon.social does not follow mitra.social. The network is comprised of actors.

What I’m saying is that ActivityPub is unnecessarily complicated for what actual traffic looks like on the fediverse. The “actor” abstraction is unnecessary unless the actor has behaviors associated with it. For just publishing posts, you don’t need any of what ActivityPub provides. Case in point: How I saved gigabytes by deleting all RSA keys shows how a single server-wide keypair is enough for the instance model. Similarly, a single server-wide shared inbox is enough for the instance model. At that point, why spin up individual actors at all? It’s just puppetry, because the instance controls everything.

OStatus used Atom and WebSub to handle this use case just fine, and arguably in a more Web-friendly way with cleaner separation of concerns. Going to a single WebSub hub and asking to subscribe to a profile is adequate logic. Messaging an actor at their inbox and notifying them of your intent to Follow them is logic that only makes sense if you explicitly want to stop caring where the actor lives, and you’re interested in actions more than results. But if you accept servers as inevitable, then you have no incentive to stop caring, and all that matters is the resulting posts. The actors aren’t actually doing anything! They’re not acting! The server is acting on their behalf. So again, why have actors?

---

Also,

@SorteKanin

there are no significant implementations in existence (afaik)

…because what you consider as “significant” is trying to replicate centralized “social platform as a service” offerings. If you say that

@SorteKanin

it is the standard that is wrong, not the implementations

then it is not due to impossibility in general, but it is due to more pragmatic limitations; notably, limitations in scope of what currently exists and has ossified significantly. The challenge is not in building the system, the challenge is in transitioning users toward that system so that you actually have people to talk to. It will never be “viable” due to network effects alone.

We are where we are today because Mastodon was in the right place at the right time due to a blunder in Twitter policy from April 2017, and then Mastodon proceeded to transition its internals to POSTing AS2 JSON instead of GETting Atom XML… because they wanted followers-only posts without having to use authenticated feeds. Since then, people have largely copied Mastodon in their implementations. This is the ecosystem you have to realize we are in – one where more people read the Mastodon documentation on ActivityPub rather than the ActivityPub specification itself, and probably a lot of those people look at the Mastodon codebase more than they read the Mastodon documentation! Because Mastodon is where the users ended up, and ActivityPub alone will not let you interop with Mastodon.

But for whatever reason, Mastodon doesn’t want to take de jure responsibility for a protocol that they de facto developed. One that involves WebFinger and in fact used WebFinger more authoritatively than ActivityPub. To the point that we are discussing “changeable usernames” as if they were this Herculean task rather than a perfectly normal thing to have. And then it leads to questioning why a specification would allow for possibilities just because narrow implementations chose to do something different? Like,

@SorteKanin

why even allow the possibility of it not being unique?

is a question that can be answered, quite simply, as: “ActivityPub was not written exclusively for Mastodon”. Again,

@trwnh

ActivityPub doesn’t depend on WebFinger in any way.

Honestly, this whole “ActivityPub” vs “fediverse” thing is just one big equivocation, because people use one term when they really mean the other thing.

[SorteKanin]

@trwnh

So again, why have actors?

I think I see what you mean - actors in ActivityPub as they are used in most instances nowadays, are just a way to avoid having to “subscribe” to everything coming from an instance. I.e. you use an actor to basically filter the messages you want from an instance so you only get certain messages, the messages from some specific actors.

Really makes me think how much simpler of a protocol that could be made if the protocol adopted the instance-based view from the start. Problem is network effects, as you say. You can’t connect to the fediverse as it is today unless you speak instance-based Mastodon-flavored ActivityPub. But what’s the path forward? I guess that’s been discussed plenty already without really reaching any conclusion other than:

1. Agreeing on an “ActivityPub 2.0” seems hard-to-impossible.
2. Migrating away from ActivityPub 1.0 seems hard-to-impossible.