What would make AP v2.0 a "complete" protocol?

One of the reasons of #software:openengiadina switching to XMPP is:

Specifically wrt Webfinger, @yvolk in this issue mentioned:

You are not the first who mentions webfinger in the context of ActivityPub. My opinion is that webfinger is not an ActivityPub way of doing things. Moreover, ActorID doesn’t have to be a WebfingerID… Please see this comment and below: #525 (comment).

So maybe Webfinger is not the best way forward. Maybe it is acceptible.

What are all the holes still to be filled in that would be part of a sensible v2.0 of the ActivityPub spec? One that preferably gets rid of application-specific ballast that is only hindering the evolution of the fediverse?

1 Like

So when we did the social web WG it was really a micro blogging WG

I suggested basing a social web on people, friends and connections (like facebook). But the consensus was around follows, and to do friends later

I think of AS as a good but not exceptional vocab, it was really IBM pushing it for their enterprise clients

My wishlist for 2.0 – this is a very generic list for SWWG – some may be added to AP2.0, others not practical

  1. Embrace JSON by default, with JSON-LD as preferred, but not a must. JSON must allow URLs for linking. Should have @id subjects and preferably a @type which is most of what JSON-LD needs

  2. Encourage JSON to live in an file, API, or importantly to be embedded in an HTML page (like schema.org)

  3. Make our own practical useful vocabs, more collaboratively, more easy to edit. less complexity, nice visuals. Again base it on JSON. People that want it in other formats can translate it

  4. First class profiles at the heart of the experience. Profiles have clean separation from the document. They have free form data that the user can add. And discovery, of followers, friends, keys, APIs

  5. Proper addition of public keys. This can be managed on the server, on the client, in an extension etc. Allowing for clean client to server, server to server, server to client etc.

  6. Integrate with your own area to store data. In solid we called this a Pod (personal online datastore). Have a simple sharing and/or access control system to allow collaboration

  7. Realtime overlay networks, that provide updates to things when stuff changes. Im not all that up to date on how that works in AP right now, other than the inbox/outbox workflow, but it seems to scale pretty well. There other things out there such as Gun and some websockets stuff

  8. More stuff in the style of a social experience like when facebook was growing. How you can add friends, friend requests, timelines, play games together, independent apps based on the social graph and permissions

  9. Embrace payments. No scams, ICOs or rug-pulls. Just honest grass roots stuff like the lightning network. Allow tipping between users. Simple web use cases, e.g. paywall, with for example HTTP 402

  10. Building on 9 some new social ideas such as the ability to show gratitude to other users. Like discourse, but in a more concrete way. ie like spendable karma. Have a distributed web of trust, which is time stamped and stored in history, so you keep your reputation over time. Tie this in to a moderation system such that each instance and each s/w defines its own rules, but that different instances cross pollinate

Apologies if that’s quite vague, just a few high level thoughts …

I don’t think that WebFinger support is required for ActivityPub. Long talk on this is here: (you may search that long thread…)

On this comment I agree with it quite a bit

Webfinger was originally a way to get some JSON back from an email address. The idea was for google and MS of how to log in when someone types an email address in

It got a bit convoluted, and somewhere along the lines, they invented their own URI scheme, acct:

That was unnecessary complexity IMO

I dont see the need for webfinger in the fediverse because people dont log in with their email address

The fedi style identifiers are pretty well established now, so you just need a place where you can get back a json blob

Funnily enough someone suggested the solution to webfinger would be very simple:
Go from:

user@host → host/@/user → give back some JSON

ie a 1 line spec, and it’s not far off what mastodon does

When webfinger came out i checked all the implementations and actually everyone implemented it in a slightly different way

This whole thing could be really simplified, and in fact all the JSON you need can be in your profile, or linked from your profile. You just need a well known way to translate in the spec.

1 Like