Bring Your Own IDentity (BYOID) #41

Open
opened 2023-09-23 13:41:20 +00:00 by julianfoad · 0 comments

Related to development of all social (people-focused) communications and sharing systems, fediverse included.

Own Domain

We can't build people-oriented social tech in the way that Big Tech do, where they say "this is our system, you'll have an address @ our-big-tech-domain, and all your links belong to us."

Earlier today I replied to Johannes Ernst who observed that people should need to think about the difference between someone's fediverse handle and their email address, they should be the same. I wrote,

@J12t Absolutely! We should just need "my address". I've been writing about aspects of this. And it's strongly tied in with the value of having one's own address at one's own domain. Don't want my email addr to be me @ mastodon, nor my fediverse to be me @ gmail :-) rather I want them both me @ my-domain. And to make that efficient and affordable, servers (and server operators) must support Bring Your Own Identity #BYOID .

https://wrily.foad.me.uk/tag:ownDomain​

Own Domain is a truly cross-platform issue. It applies to matrix just as to fediverse and others. It's about bringing the person to the centre.

A recent key insight I had was actually "my own" registered domain isn't necessary. A substantial part of the value is in having an address at a domain that isn't belonging to a particular one of the service providers we use, but in having the use of an address at a domain that belongs to someone, anyone, whom we trust to let us use it for the long term. Could be a company, one's government, a charity. The key is to be able to switch and mix service providers without borrowing a new and different address from each one.

Main issues include:

  • getting server software to support BYOID
  • getting server operators to support and encourage BYOID (and adapt to doing their brand recognition a different way)
  • making domain registration easier and cheaper and reliable for ordinary folks (includes sub issues such as: facilitating subdomain use, see Public Suffix List)
  • making domain management easy, standardised, automated, at least as far as enabling providers of matrix/mastodon/etc. be able to plug in their service to my domain with minimal effort on my part)

I'm presupposing, by bringing up this topic in this forum, that a majority of readers here will understand the reasons why this direction makes sense. (That's something I have tried to write about on my blog but, though I try, explaining and appealing to normies to understand the importance is not my forté.)

I feel like we're missing something, that having all my different protocol addresses matching isn't merely about being easy to remember, it's not a trivial nicety. It's somehow a key to building deeper integration of our personal data within our personal tech. It's hard to think of use cases that can't be achieved by linking to external sites the way we do now, but my intuition is integration can be done better this way.

And I think BYOID goes a huge way towards solving the account "portability" issue.

Yet our delightful new federated things, wonderful in themselves, are yet, still, being built as big tech mono-sites: "join us and get our lovely service at our address" (mastodon.anything, fedi-thing.whatever, matrix-circles, matrix.org, beeper.com, on and on add infinitum).

Only a few rays radiate in the right direction:

  • ye olde email (BYOID is widely available)
  • Blue Sky spec (but, sadly, not the blue sky central server)

(I thought I'd be able to name more.)

Running the service oneself, be it email or fedi or matrix, isn't easy. I self-host only in order to bring my own domain, not because I want to. Currently without self-hosting I explain it as I'm Unable To Be Me .

Discussion:

  • Social Coding FSDL matrix room #socialcoding-foundations:matrix.org (alternate link)

Related:

Related to development of all social (people-focused) communications and sharing systems, fediverse included. **Own Domain** We can't build people-oriented social tech in the way that Big Tech do, where they say "this is our system, you'll have an address @ our-big-tech-domain, and all your links belong to us." Earlier today I [replied](https://fed.foad.me.uk/notice/Aa3LVlD2Ex7jOOi2fg) to Johannes Ernst who [observed](https://social.coop/@J12t/111111692215312791) that people should need to think about the difference between someone's fediverse handle and their email address, they should be the same. I wrote, > @J12t Absolutely! We should just need "my address". I've been writing about aspects of this. And it's strongly tied in with the value of having one's own address at one's own domain. Don't want my email addr to be me @ mastodon, nor my fediverse to be me @ gmail :-) rather I want them both me @ my-domain. And to make that efficient and affordable, servers (and server operators) must support Bring Your Own Identity #BYOID . https://wrily.foad.me.uk/tag:ownDomain​ Own Domain is a truly cross-platform issue. It applies to matrix just as to fediverse and others. It's about bringing the person to the centre. A recent key insight I had was actually "my own" registered domain isn't necessary. A substantial part of the value is in having an address at a domain that isn't belonging to a particular one of the service providers we use, but in having the use of an address at a domain that belongs to someone, anyone, whom we trust to let us use it for the long term. Could be a company, one's government, a charity. The key is to be able to switch and mix service providers without borrowing a new and different address from each one. Main issues include: - getting server software to support BYOID - getting server operators to support and encourage BYOID (and adapt to doing their brand recognition a different way) - making domain registration easier and cheaper and reliable for ordinary folks (includes sub issues such as: facilitating subdomain use, see Public Suffix List) - making domain management easy, standardised, automated, at least as far as enabling providers of matrix/mastodon/etc. be able to plug in their service to my domain with minimal effort on my part) I'm presupposing, by bringing up this topic in this forum, that a majority of readers here will understand the reasons why this direction makes sense. (That's something I have tried to write about on my blog but, though I try, explaining and appealing to normies to understand the importance is not my forté.) I feel like we're missing something, that having all my different protocol addresses matching isn't merely about being easy to remember, it's not a trivial nicety. It's somehow a key to building deeper integration of our personal data within our personal tech. It's hard to think of use cases that can't be achieved by linking to external sites the way we do now, but my intuition is integration can be done better this way. And I think BYOID goes a huge way towards solving the account "portability" issue. Yet our delightful new federated things, wonderful in themselves, are yet, still, being built as big tech mono-sites: "join us and get our lovely service at our address" (mastodon.anything, fedi-thing.whatever, matrix-circles, matrix.org, beeper.com, on and on add infinitum). Only a few rays radiate in the right direction: - ye olde email (BYOID is widely available) - Blue Sky spec (but, sadly, not the blue sky central server) (I thought I'd be able to name more.) Running the service oneself, be it email or fedi or matrix, isn't easy. I self-host only in order to bring my own domain, not because I want to. Currently without self-hosting I explain it as [I'm Unable To Be Me](https://wrily.foad.me.uk/im-unable-to-be-me) . Discussion: - Social Coding FSDL matrix room [`#socialcoding-foundations:matrix.org`](matrix:r/socialcoding-foundations:matrix.org) ([alternate link](https://matrix.to/#/!kmRMUxStNfioKGDmFN:matrix.org?via=foad.me.uk&via=matrix.org&via=tchncs.de)) Related: - Idea [#23 Domain names as handles](https://codeberg.org/fediverse/fediverse-ideas/issues/23)
Sign in to join this conversation.
There is no content yet.