Re: Let's turn aspiration into fact?

st 7. 2. 2024 v 18:57 odesílatel Johannes Ernst <johannes.ernst@gmail.com>
napsal:

> According to David Pierce at The Verge in a piece
> <https://www.theverge.com/24063290/fediverse-explained-activitypub-social-media-open-protocol> published
> today, the Fediverse is:
>
> … an interconnected social platform ecosystem based on an open protocol
> called ActivityPub, which allows you to port your content, data, and
> follower graph between networks.
>
>
> He continues:
>
> If you wanted to leave one platform for another, you could bring all your
> content, all your followers, all your everything with you.
>
>
> This is aspirational compared to the state of implementation today, but a
> very reasonable aspiration IMHO. I would be prepared to argue that this
> aspiration — and a few other bit and pieces he isn’t mentioning — are
> essential to become real in order to deliver on the promise that people
> already think we are making. (Anecdotally I have found that many people
> believe this, not just David)
>
> What are our aspirations in SWICG here, specifically with respect to
> future standards work?
>
> It’s very important that we document what works today, I appreciate the
> people who are stepping up right now, and don’t want to distract from that.
>
> But once we have captured the present, where are we going? As a straw
> proposal, I propose that we adopt the two above sentences from today’s
> Verge piece as a vision, e.g. as “We develop the standards (and whatever
> else is necessary) that make easily possible … (see above)”.
>
> 1. Does this vision sound reasonable to you?
> 2. How can this very straw-y proposal be improved?
>
> P.S. Yes, I understand that we won’t (want to) squeeze Lemmy into
> Mastodon. So add the qualifier: within reason or such.
>

My experience of the evolution of data portability and migration in
federated systems like Solid has presented significant challenges.
Originally, Crosscloud, as a precursor to Solid, aimed at enabling users to
move their data across platforms seamlessly, as highlighted here:

https://knightfoundation.org/articles/introducing-crosscloud-project-get-your-data-out-silos/

However, Solid, focusing on Social Linked Data, didn't inherently
facilitate migration, despite aspirations towards it. Efforts to address
migration within Solid encountered technical hurdles, partly due to the
project's foundational design not aligning with nomadic identity principles.

Nostr, conversely, is explicitly designed to support seamless user movement
across platforms without the complexities of a traditional migration
process. Its architecture inherently accommodates nomadic identities,
making transitions effortless and immediate. Moreover, Nostr's capacity to
integrate with federated systems through NIP-05 implies a promising
approach to bridging different technological ecosystems.

The challenges faced by Solid, exacerbated by startups overpromising on
portability and migration capabilities, underscore the importance of clear
messaging and realistic expectation setting. The core issue lies in the
architectural and topological constraints, which make adding migration
features to a federated protocol inherently complex, especially in
achieving a unified user experience across a large ecosystem.

A pragmatic solution lies in leveraging the strengths of each protocol,
facilitating user choice through interoperability bridges. For instance,
integrating Nostr keypairs with Fediverse profiles, and vice versa,
simplifies user interaction across systems. This strategy, which I plan to
incorporate into projects like microfed and solid lite, and parallel
efforts by Alex Gleason in tools like ditto, soapbox, and mostr, emphasizes
using the right technology for specific needs.

It's crucial to manage user expectations by clearly communicating the
capabilities and best uses of each system, ensuring users are well-informed
about their choices in the wider fediverse.


>
> Cheers,
>
>
>
>
> Johannes.
>
> Johannes Ernst
>
> Fediforum <https://fediforum.org/>
> Dazzle Labs <https://dazzlelabs.net/>
>
>
>
>

Received on Thursday, 8 February 2024 20:14:00 UTC