- From: Bumblefudge <bumblefudge@learningproof.xyz>
- Date: Thu, 08 Feb 2024 02:27:50 +0000
- To: public-swicg@w3.org
- Message-ID: <4d80783a-d2c6-4163-8559-7512bcbf8901@learningproof.xyz>
I would argue (to anyone considering stepping up to lead such an effort) that the data portability task force/report-writing effort isn't necessarily a lot of *net-new design work* or even *picking between solutions*, so much as it might consist primarily of coordinating and assessing work already happening that is often complementary and composable rather than competitive. I just opened a meta-FEP for tracking this stuff against user stories, which could double as (or become) the to-do list of a task force, or at least a major input to such a report: https://codeberg.org/fediverse/fep/src/commit/ce1968f83462efe9d9a8be57ca1a25443bd08d56/fep/73cd/fep-73cd.md Feel free to contribute in any way you see fit, fork, etc? Thanks, __bumble On 2/7/2024 3:04 PM, Evan Prodromou wrote: > We currently have 3 important subgroups in this CG: > > * Testing task force > * ActivityPub + Webfinger report team > * ActivityPub + HTTP Signature report team > So, at TPAC last year, we decided to open a Data Portability Task Force. We have a draft report on data portability here: > > https://w3c.github.io/activitypub/data-portability-report.html > > We need a few people to take on the role of organizing this task force. If you're interested, please talk to the chairs. Having 1-2 people take this on would be a huge help. > I'd love to see this move forward. In particular, I'd like to see more server software support bring-your-own-domain (BYOD) and I'd like to see an effective standard for transferring content and reactions (likes, replies, shares) between servers. > > Evan > >> On Feb 7, 2024, at 5:08 PM, Johannes Ernst [<johannes.ernst@gmail.com>](mailto:johannes.ernst@gmail.com) wrote: >> >> Suggest that before we discuss HOW something could be done (whether FEPs, Zot, whatever …) … >> >> … we need to get some forward momentum on WHAT should or needs to be done. >> >> My straw proposal, taken from the Verge article, is fundamentally about the WHAT: take your followers, take your content, take “your everything” as he put it. >> >> Traditionally, this group has said, more or less, “things are fine, no need to do anything”, and I’d like us to get out of that mode, specifically towards what “leading users” like David @ the Verge would like us to have done already. “Doable aspiration” as he put it in a comment. >> >> Cheers, >> >> Johannes. >> >> Johannes Ernst >> >> [Fediforum](https://fediforum.org/) >> [Dazzle Labs](https://dazzlelabs.net/) >> >>> On Feb 7, 2024, at 13:23, Scott [<sstolz@wistex.com>](mailto:sstolz@wistex.com) wrote: >>> >>>> If you wanted to leave one platform for another, you could bring all your content, all your followers, all your everything with you. >>> >>> We already have this capability with Hubzilla via the Zot protocol, and Streams via the Nomad protocol. If ActivityPub could adopt these features, it would bring this feature set to more people. >>> >>> The way Zot and Nomad protocols handle it would be a good model to start from. We've been using it for over a decade now, before ActivityPub even existed. It may not be popular because it was never promoted properly nor well-documented, but it is tried and tested. (And now that we formed the Hubzilla Association and I was elected its President, we are going to make sure our unique feature set is documented and promoted properly.) >>> >>> If you were to implement a similar feature set, some things that would be necessary include: >>> >>> 1. Portable or Nomadic Identities would need to be based on cryptographic keys, not a URL or channel address (someone@example.com). That way the identity can be recognized as the same person or channel even though it moved servers. >>> >>> 2. Ideally, there is a common export and import format that can be used for multiple platforms. You could export your identity and data from one platform and move it to another by downloading a file from your existing server and then uploading it to the new server. >>> >>> 3. If you want to get fancy, you could do a sync between accounts so there is no download required. You authenticate on both platforms, and issue a "sync" command to either migrate or make a clone of your account. >>> >>> 4. If you really want to get fancy, you would implement "nomadic identity" in addition to "portable identity." They are similar, but the key difference is that with nomadic identity, your identity can exist on more than one server at a time, whereas a portable identity is for migrating from one server to another. >>> >>> Both the Zot protocol and the Nomad protocol have already implemented all four of the above. >>> >>> Ideally this functionality is part of ActivityPub and the different platforms get to decide if they make that functionality available to their users. >>> >>> I know that with Hubzilla, we are redesigning our website, documentation, and user interface to promote nomadic identity and federated single sign on. And we plan on using this as a reason to choose Hubzilla over ActivityPub-based platforms. >>> >>> Your identity is already portable and nomadic on our platform. Hopefully we can get the rest of the fediverse onboard with the concepts of nomadic identity and federated single sign on. >>> >>> Any way that I can help, I am here. >>> >>> Scott M. Stolz >>> President, Hubzilla Association >>> Director, Federated Works >>> Founder & Manager, WisTex TechSero Ltd. Co. >>> >>> On 2/7/2024 1:15 PM, Lisa Dusseault wrote: >>> >>>> I can get behind that aspiration. I think there are important use cases to verifiably bring one's social history along in a move, and that users moving among servers is rather key to ActivityPub's moderation architecture working well. Server administrators won't feel empowered to defederate servers with policies they can't accept, if many well-connected well-behaved users are stuck on that server. >>>> >>>> To make proposals more concrete, we could write some proposed requirements first, identify the key use cases -- if there is energy to do that, otherwise wait and focus first on the existing stuff, right? >>>> >>>> Lisa >>>> >>>> On Wed, Feb 7, 2024 at 9:56 AM Johannes Ernst <johannes.ernst@gmail.com> wrote: >>>> >>>>> 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. >>>>> >>>>> Cheers, >>>>> >>>>> Johannes. >>>>> >>>>> Johannes Ernst >>>>> >>>>> [Fediforum](https://fediforum.org/) >>>>> [Dazzle Labs](https://dazzlelabs.net/)
Received on Thursday, 8 February 2024 02:28:20 UTC