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?
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
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
Encourage JSON to live in an file, API, or importantly to be embedded in an HTML page (like schema.org)
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
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
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.
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
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
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
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
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.