Idea: Fediverse Profile UI component fed by Keyoxide back-end service

Move your thoughts 💭 Ideas
#1

About a year ago I dropped a rough thought on how @yarmo’s Keyoxide could be used on the Fediverse:

That wasn’t very concrete… here a further idea:

Keyoxide Profile component

Idea boils to the following UI to be hydrated (almost) competely via a reference given to one’s Keyoxide Profile. Just drop the URL and fedi profile is filled out with all profile links verified.

my-mastodon-profile-snapshot
my-mastodon-profile-snapshot404×969 240 KB

#2

I think that’s a clever application. So roughly:

1- You configure somewhere on the fedi profile your Keyoxide profile
2- Clients get the verified identities from Keyoxide, and show the matching links as verified

Is this the idea? And how would this work for fedi instances that do not have these “attached links” like Mastodon has?

1 Like
#3

Mastodon only has space for 4 links, but for instance @bashrc has many field display options in Epicyon.

I think implementation-wise there should be multiple version of this component, dependent on what lang the app is using, but once the component is created in a language for one app it might be easily reusable in others. On Keyoxide side I don’t know requirement to best serve the hydration, but seems like this is not a tough requirement.

#4

Agreed, on the Keyoxide side it should be simple. The tough part will be making sure clients perform the steps in a consistent way.

#5

With clients you mean devs adopting the component, or people using it in an app? In both cases it may be a ‘thorough documentation’ bullet point to address…

#6

Yes, I meant clients = devs adopting the component. But whose “initiative” should this be? Keyoxide? Or ActivityPub? It will be quite the responsibility if you envision this being “Keyoxide extending ActivityPub”. Though granted, it will likely be the only possibility for this to ever see the light of day.

#7

There are multiple ways this can be implemented. What I had in mind does not involve extending ActivityPub. It would more an app codebase integration of the component that stands on itself. The app would fetch the data, and also be responsible to keep it in sync, then uses that for communicating any Actor messages it sends across the wire, but no different than what it already does.

#8

Many open standards can support profile hydration:

Ariadne
Map an email identifier to supported verified accounts.
The IndieWeb
Map a webpage with h-card to any account. This can pair with other forms of authentication, such as RelMeAuth.
WebFinger
Map an email-like identifier (an acct: URI) to a list of links.
vCard
Mpload a vCard containing profile information, possibly with “share contact”.

I think h-card-based hydration is the best place to start. We can later add support for more options:

  • Keyoxide profiles already contain h-card microformats, so we get that for free.
  • h-card microformats can have u-key properties, potentially triggering an Ariadne-based verification of accounts enumerated by the h-card.
  • h-card can map to vCard4

Depending on how keyoxide-web issue 141 goes, WebFinger could also indirectly give Keyoxide support.

POSSE note from https://seirdy.one/notes/2022/10/26/profile-hydration/

1 Like