narF 😵✌️One thing I miss from the golden age of #Facebook, when pretty much everyone was on it and kept their #profile up to date, was that it was easy to find how to message someone. When I wanted to contact someone who I hadn't talk to in a while, I just used Facebook. I didn't had to worry that I had a wrong or outdated email address. I could see their profile to make sure it's the right person, and that they had been active recently so my message wouldn't get lost in the void. It was reassuring.
This is something that #email never achieved. Sure, email apps save our list of contacts, but that's not the same. It places the burden on myself to maintain the list. To make sure that the hundreds of addresses that I collected are still up to date, well categorized, named properly, etc.
Some people have multiple addresses and it's hard to know which one they want me to use for sending personal messages. Plus their phone number! Plus their Discord, Whatsapp, Signal, Slack, Steam, Facebook, Twitter usernames.
What a mess! Which one should I use? Some people have been calling this the "App Fog" (https://element.io/blog/what-is-app-fog-how-do-i-solve-it/) for when you have so many apps and you need to remember which one to use for each friend.
Each of us has the burden of maintaining our contact books. That's a lot of duplicated efforts! In a group of 10 people, each of us as to maintain 9 contacts. That's 10 x 9 = 90 duplicated efforts!
I wish there would be a way to share that workload. If each of us maintain our own contact infos and make sure to keep it up to date, just like we did on Facebook back in the days, then that's a lot less duplicated efforts!
In a group of 10 people, each of us as to maintain only 1 contact (our own). So that's 10 x 1 = 10. No duplicated efforts!
So how do we get there? How do we make a system that is as practical as Facebook was back in the day, but not centralized in the hands of a private company?
And what would it look like in practice?
Here's how I would imagine a decentralize and federated contact book:
When someone want to give their email or phone number, instead of giving it directly, they would give you their "contact book profile", which would be an web address that would be short and easy to remember. (ex: contactbook.org/narf)
#federatedContactApp #decentralizedContacts #email #federatedProfile
You could open that web address using any browser to see the person's public profile, which is a good default if you don't have a compatible contacts app. This public profile would list public information that your friend want to share, like maybe their Linkedin profile or work phone number and a short bio.
#FederatedContactApp #federatedProfile #DecentralizedIdentity
But if you do have a compatible contacts app (and ideally, all currently existing contact book apps would support this open standard) you can add that URL in your app to save the profile of your friend. At the start, you only see their public profile. But you can then send a friend request to see their private info, which would include things like their personal email address, personal phone number and home address.
#FederatedContactApp #FederatedProfile #DecentralizedIdentity
You should have total privacy control of who as access to your personal information. For example, you could hide your phone number by default and people would have to send you a request before seeing it. And would could decide for how long to give it access to: forever or maybe just a couple months? (The default could be something like 2 years.)
#FederatedContactApp #federatedProfile #DecentralizedIdentity #privacy
The intent of all this system would be that once you've added a friend in your contact book app, their profile would be kept up to date automatically. If they change their phone number, they change it on their profile and your contact app automatically updates itself with the new info.
Of course, if your friend wants to keep their new phone number private, they could do so. Your app would display that their phone number is outdated and that you need to request access again.
This system should be an open standard, so that all existing contact book apps could implement it. Kinda like an updated version of CardDAV (https://en.wikipedia.org/wiki/CardDAV).
And ideally, all of that would be end-to-end encrypted, so that only your friends get to see your personal data. The host where you store your profile and your friends hosts should not be able to read your contact info!
#CardDAV #openStandard #FederatedIdentity #FederatedContactApp #E2EE #E2EEncryption #encryption #privacy
And because it would be an open protocol, you could decide who you trust with your personal data. Sure, you could use #Facebook or #Google, but there would be plenty of independent hosts, just like there are thousands of email providers and phone companies!
Or you could #SelfHost it on your own personal website/server if you have one. I can imagine extensions for Wordpress, Squarespace, Linktrees or wherever people host their website these days.
Of couse, it could also be provided by your existing email provider (but, again, maybe you don't want to trust #Microsoft or #Google with that! lol)
And because the quantity of data to store is small (a few text fields and maybe a couple profile photos), the cost for hosting would be quite low. Way less expensive than running a #Mastodon or #Email server.
Do you know any existing services that do something like that? Am I trying to re-invent something that already exists?
#DecentralizedIdentity #decentralizedContacts #FederatedContactApp #FederatedIdentity #ContactApps
Now let's talk about #UX! (#UserExperience)
For something like this to work, for people to want to use it and ditch #Google and #Facebook, it would need to provide excellent user experience.
For example: how do we make sure that people keep their profile up to date? This proposed system would be no better than our current #ContactBooks if they are always outdated! This is more than a technical or UI problem. It's a user experience problem!
👇
One possible solution would be to prompt the user, maybe every 3 months, to validate 1 piece of data of their profile.
"Do you still use 555-555-1234 as your personal phone number?"
"Do you still use [email protected] as your email address?"
We don't want to ask too frequently, and we don't want it to take a long time to validate. It should be a simple yes/no question.
Your profile could even display when it was last validated next to each field, so that your friends know it's not outdated. It would be reassuring to know that I'm about to send an email to an address that was validated less then 6 months ago. At least I'll know I'm not about to talk to a void!
#UI #UX #federatedProfile #FederatedIdentity #decentralizedContacts
Another problem to anticipate: What if the profile host of a friend is temporarily or permanently unavailable?
Well it wouldn't be that bad since you would still have your local copy of your friend's profile in your contact book app. That's the beauty of local-first data storage!
Also, for maximum redundancy, we could think of a backup system. Your profile could hold a link to a backup profile of yours, hosted with another provider and kept automatically up to date. Kinda like a git mirror server or when your hospital ask you for parent/friend number in case of an emergency.
Another difficulty that come with decentralization: What if you want to migrate your profile, including all your address book, to a new host because your current host is problematic? It should be easy to migrate, without losing any of your friends or their data.
We can look at existing decentralized system and how they attempt to solve migration:
#decentralizedContacts #accountMigration #decentralizedIdentity