FlockingBird Profile Portability (FPP)

[stevefloyd]

FlockingBird Profile Portability

I love the concept behind this project and what it seeks to accomplish, that is why I am here. Wanted to post this here for discussion and flesh it out before an official RFC proposal.

One issue in the Fediverse that has not been adequately discussed is portability.

This is something I have been pondering for a while and wanted to get feedback to flesh out potential solutions.

I have felt that the way applications handle privacy and permissions have been backward from the beginning. You shouldn't have to tell every single app you join what your preferences are. They should know them and respect them when you join (assuming you have an existing OAuth or open standard compatible ID of some kind).

An attribute I would like to see in Flockingbird, one key differentiator / innovation that sets it apart would be advanced profile portability tools baked in. So people can effectively take their profile and related data with them easily.

Looking over your specification dealing with profiles, half the work is already done.

Abstract

I am still deciding the best way to go about it, but here is a brief abstract...

A persons Flockingbird profile is essentially a permissioned / ACL enabled vCard. If you took the granular profile control from Hubzilla and combined it with the directory / object permissions you see being developed in @solid, you would have something that looks closer to this ideal outcome.

Finding a means to anchor the account (i.e. a public proof) could be decided by the user based on what they already use (or generated for them the way you do now).

• If they have a WebID, use that.
• If they use Metamask and have an Etheruem or Polkadot account, use @ceramicnetwork.
• If they already have a DID or SSID that is in an open standard format, use that.
• If they don't have any of it, use Keyoxide and whatever you already use now (your server being the authority).

Flockingbird could become the "Facebook" connect of the Fediverse in that regard.

Potential Solutions

There have been many projects over the years that have attempted to solve Decentralized and Self-Sovereign ID, and all of them have trade offs. Aside from the aforementioned projects, here are some projects that may provide solutions...

• Hypercore Protocol
• Hyperdrive
• Hyperspace
• 3ID-Connect
• JS-IDX
• Ory

[berkes]

Thanks for the time and research.

I'll need to investigate the resources a bit further before I can reply in more detail on the technicalities.

More high-level, though, is a conceptual hurdle to take: The difference between decentralized and federated. The fediverse is a middleground between real P2P, absolute decentralization on one side, and centralisation on the other. A mastodon instance is closer to what most people are familiar with: register at a server and start using the network.
It is a pragmatic approach, that is far from truly decentral social networks as steem or dtube (often blockchain or IPFS based).

Flockingbird chose Activitypub and the Fediverse as model, because of the pragmatic and familiar approach. We believe AP/Fediverse to be a step towards full decentralisation.

Another relevant thing to highlight is how Flockingbird will focus more on the profile and less on updates/messages/posts. That makes us different from most other ActivityPub software around currently. From Peertube, via Pixelfed to Mastodon, treat a profile as a static given. Changes to e.g. you avatar or bio is not distributed over the fediverse, but uses syncs and local caching.

Taking both into account, brings us the high level of whether AP is a) a good solution to distribute changes to a vcard/profile/resume over, or whether another, maybe more decentralised system is better suited.

Or, more practical:

• registering at an instance that works and feels a bit like the already familiar LinkedIn, make transition easier.
• tapping into the existing fediverse gives a potential user-base.
• new paradigms like blockchains, (data)wallets, specialised clients (dat://) or browser-addons (metamask) make adoption really hard and introduce a broad spectrum of unsolved issues (IMO Steem, for example, is a failure due to moderation issues that are impossible to solve due to the model).
• using activiltypub to distribute a user-profile on the fediverse is new and uncharted land in the fediverse. Not sure how and if this will work.
• having instances limits the privacy- and access- model. And makes it complex; more complex than in either a true p2p or in a fully centralized setup.
• relying on instances limits freedom to move around. I'm unconvinced this is a real and practical problem in the fediverse though¹

In addition to researching the options given, I'll spend some time to investigate possibilities to overlay a Flockingbird profile with something that increases portability.

E.g. a JSON Resume (#34) export or variant, may be enough for most people to take their profile and move elsewhere. Or the model to move between instances as offered in mastodon may be enough as well. But maybe some feature that syncs all profiles (e.g. the JSONREsume version) on IPFS, and then exposes the IPFS id may work as well.

---

¹ And I say that as a long-time fediverse-user who was once blocked and booted from an instance, without warning, by a powertripping mod. So no opportunity to use the "download backup and move to a new instance" features at all. One hour happily tooting, the next hour blocked and deleted. Still, the incident was 🤷🏿 in practice. A day and some manual work later back up at a new instance, with many of my followers back.

[stevefloyd]

We are on the same page, I think you are misunderstanding me a bit. Your perspective is accurate, but I’m not trying to achieve decentralized utopia, just a backup point for mere mortals and options for technical people (and maybe establish a standard for how to handle this stuff in the process).

I helped launch several public blockchain networks and was a block producer who helped validate transactions on those networks - so I understand the nuances between federated / decentralized networks deeply.

I showed up here because of my disillusionment working in those other communities and seeing how centralized things really were behind the scenes.

For this idea, I am advocating using existing open standards outlined in the W3C did-core specification and simply adding a public proof to anchor the account and generate a small JSON file (with their permissions / vCard data) pushed to an IPFS, Hypercore or public blockchain (or just your server with the default method) of their choosing upon registration. The key generated when they sign up is the signing key to access and download their profile data.

Reading over your response a few times, we are thinking the same way about how to solve this and I think once you go over my resources more, you will see what I am saying.

When you step back and think about it, a profile is just a vCard with @OStatus identifiers added to it.

The same fields that people put out on their public profiles for business has been pretty static for the last 20+ years...

• First name
• Last Name
• Email
• Phone Number
• Address
• Links / URLs
• Work History / CV
• Connections / Friends
• Updates / Content Feed

It would make sense to ensure these fields and the users preferred permissions to whom they share those fields with (public vs private or connection / network based) could be as easy as clicking an "export" button on their profile.

A user would still register just like they normally would, you would just add an additional step / question during registration on how they would like to handle their profile data.

• They can host with you and use your default method for the least friction
• They can use their existing WebID or OAuth profile
• They can use Metamask (utilizing Ceramic IDX, 3ID Connect, or another DID provider to be discussed)

The idea is to have an anchor for their GPG keys that is associated with their account, and then being able to use that to push to a DHT table on IPFS, or Hypercore (it appears Hypercore is more suited for this from my research).

This is a big problem and if it was easy to solve there would already be a lot of solutions available. I think it is worth exploring more and thinking out more in these early phases.

Even if we can't achieve 100% portability and interoperability, at least trying to take a first stab will move the ball forward (and provide a much needed innovation in the ecosystem in the process).

[berkes]

I like the ideas posed here. DIDs sound like a fantastic feature.

To make it practical and place it in context, I'd like to think about where this belongs. Some questions that we'd need to answer are:

• Can this be an additional feature that comes after an MVP or other features, or must it be part of the core?
• How does planning such a feature limit us now. E.g. will it require or disallow, certain standards (e.g. vcard, jsonresume)?
• Will it interfere with Activitypub-for-profile-data or can it live next to it?

I'm trying to establish how far we need to research and document this now, and how far it needs to be embedded in an MVP. Or if it can safely be placed on a backlog. And whether this can be implemented separately (either as part of an MVP or not) or whether it needs to be part of a core.

[stevefloyd]

After having some time to sleep on it and look through all the design comps and features more, this would just add an additional layer of complexity (for you and for end users) so it definitely isn't fit for MVP.

I also read your blog on being weary of complex security models and totally agree.

Less is more, and this is especially true with software in many cases.

Because the project is still in its early phases, I wanted to pose the question and make a case for this approach. I'm beginning to think rather than baking this into a Federated network, this is an entirely different product altogether.

Maybe rather than the platform serving this up, developing simple features that allow FlockingBird to interoperate / integrate with a standard (like a data pod or data wallet). That may be as easy as adding a JSON import feature for contacts and profile data.

#34 addresses this for the most part and can be extended later.

On a side note, you posted the wireframes and design progress in the README before I posted this, so I didn't see the full scope of everything you are working outside of the code. Now that I have a more clear picture of where you are headed, I could probably knock out the design comps over the next week or so to get things moving.

Maybe starting with a design system and branding guide would be good, as it would inform the rest of the UI, website, etc...?

A Jitsi meeting to go over priorities would be good. I have a block of time opening up, so I could get a lot done (but would be good to have a brief to ensure I am not missing anything).

[berkes]

Maybe starting with a design system and branding guide would be good, as it would inform the rest of the UI, website, etc...?

A Jitsi meeting to go over priorities would be good. I have a block of time opening up, so I could get a lot done (but would be good to have a brief to ensure I am not missing anything).

Let's do that! Please drop me a line on [email protected] to find a date and time for such a meeting

[stevefloyd]

I already emailed you at that address yesterday.