Universal profiles on the open social web

Discussion
1

One of the discussions we had during the community day ahead of Eurosky was about this notion of interchangeable user profiles in the Atmosphere / Open Social Web.

@laurenshof.online even recorded the entire conversation so maybe there’s a transcript I could clean up for us? Anyhow, here’s the gist of it.

Deferred profile

Right now on roomy.space if you sign up with your existing Bluesky account, we will defer to that Bluesky profile for your profile in Roomy as well, essentially recognizing that user’s Bluesky profile as their ‘atproto profile’.

Now, if someone signs up to tangled.sh as the start of their atproto experience and primary account, then signs up to roomy.space with that account, we’d like to defer to their tangled profile in the same way we do for Bluesky.

There’s a missing piece here for a ‘social web profile’ standard; a sort of gravatar on steroids. Whether it should or needs to be tied directly to the AT protocol is an open question.

Everyone gets a website

The ‘universal web profile’ is closely aligned with the Linktree convention, which essentially says that if you’ve got a:

  • avatar image
  • name/handle
  • description
  • one or more links

..you’ve got yourself a digital profile, aka a personal web page! That was essentially the premise of Weird, the spiritual precursor to Roomy.

We’re still intent on merging the original vision of Weird into Roomy as a ‘Personal Space’ extension, and we’re hoping to see this convention of ‘every social network profile is also a website’ become commonplace in other Open Social platforms like tangled, Bluesky etc.

There are already some dedicated linktree-type apps in atproto space as well, some of which could conceivably be some people’s first stop into the atproto network, like the lanyards.app by @renderg.host

I just got off a fun call with @zicklag.dev talking about this, so I’m gonna let him continue jamming from here.

10 Likes
2

Was there any thoughts about this being a dedicated service entry in the user’s DID document (in the PLC directory)? A user could decide (and change) which of their profiles…Roomy, Bluesky, Tangled, self-hosted etc. they want as their atmosphere profile as long as it conforms to a defined lexicon type.

4 Likes
3

Yeah, that’s exactly what I was thinking!

The exact spec would need bike-shedding, but we could literally just put a URL to a JSON file that matches a specific lexicon in the PLC record.

To me it’s actually very important that the profile information can be attached to your universal web ID and referenced from your DID document, without needing to be hosted on an ATProto PDS. I’ve got some broader ideas related to that that I’m going to start another topic on.

3 Likes
4

I feel like some of these questions and possibilities have been discussed at length in the Internet Identity Workshop and Rebuilding the Web of Trust communities. There are personal security implications here that may not be obvious. Let me see if I can find someone to pull into this conversation.

4 Likes
5

Finished articulating those ideas here: The Case For Universal Login and "Off-Protocol" Services.

1 Like
6

I lean toward the extreme side of the privacy debate. There is no doubt privacy issues that need vetting when deciding to disclose personal identifying information. End users should have final authority on their profile(s) visibility. That doesn’t change the fact that Bluesky and other profiles are 100% public today. The original post highlights common issues AT Protocol conversant apps are encountered and the confusion its causing users. Looking forward to healthy debate that can move the conversation in a positive standards-based direction.

7

the extreme side of the privacy debate is to disallow personally identifiable information and user-generated content (UGC) into did documents programmatically, so ”alsoKnownAs”:[”firstnamelastname.bsky.social”]is already far from what I would call robust privacy protections…

Each new service you connect a DID to and produce public, nonrepudiable UGC with is another chance to completely doxx all other usage of the DID, so in a way the least careful possible usage of a DID is a privacy vector all other uses of the DID have to account for and in some cases be vulnerable to. This is part of why many on the original DID WG at W3C were against open-ended/arbitrary services and serviceEndpoints in the first place. i think the extreme privacy position is “no services in DIDs period” :sweat_smile:

in any case, INSOFAR AS we can bracket all those qualms and treat a plc did as a “professional name” or hung shingle for legal persons and pseudo-legal persons, and INSOFAR AS we can trust/force users to assume their own risks doxxing themselves and publicly linking all their did:plc usage on their PDS, the case for a linktree-like profile (I use Weird myself!) is a pretty strong one. Someone can probably infer from the first entry in alsoKnownAs what their prefered/primary/oldest homepage/home-app is, but it’s definitely better to be able to signal preferences explicitly (and for apps to be able to consume that signal for better UX). verifiable messaging endpoints/identifiers/addresses are also extremely valuable since a given profile might have multiple inboxes ranked by preference…

I remember Anuj and @snarfed.org were talking at a FediForum (or was it an ATproto event?) about some kind of “verifiable bidirectional linkage” between accounts, machine-readable and straightforwardly surfaceable in the UX of different networks. That might also be relevant here, because I think there is both in-protocol utility (how does this atproto account relate to other atproto accounts) and cross-protocol utility (how can this atproto account link to an account on activityPub/venmo/gofundme/etc they also control).

I’d recommend compiling a user-stories list/doc first, because we might all mean slightly different things…

2 Likes
8

On profiles, yes we can come up with some standard fields. But I actually think that a sort of meta might work better - a “this is a profile for this app” and maybe some mappings to common fields?

As an app developer, I don’t know why I would want to pick a common profile right now? Especially if I’m going to extend it with app specific features?

I think Gravatar or Linktree are good products (potentially). This would mean building such a thing and then getting app developers to integrate these default fields.

I also think it’s adjacent to “make it easy to login and sign up” … and we’re back to tinkering with ATProto auth and PDS requirements :wink:

2 Likes
9

Yes! Bridging identity with account links

2 Likes
10

“…but my canonical/main profile is here” (or, at least, “…and a more permanent/watched profile is here”) is a useful thing to be able to say, and an even more useful thing for a client to put a little colored checkmark next to!

I like that my only contribution to the minutes of the ryan and anuj’s FediForum session in June was a link to my Weird.one profile :sweat_smile:

To be more explicit, the way I already use wierd.one and usernames is a clunky/manual/implicit version of what zicklag and erland are trying to advocate for, and what ryan and snarfed documented seem like an essential building block for making the latter smoother and scalable/trustworthy. I say “manual” because it requires the end user to click through to find out what a checkmark could automate and tell them already…

3 Likes