Re: Let's turn aspiration into fact?

čt 8. 2. 2024 v 2:04 odesílatel Bob Wyman <bob@wyman.us> napsal:

> Johannes wrote:
>
>> "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"
>
> I disagree. The Verge article's
> <https://www.theverge.com/24063290/fediverse-explained-activitypub-social-media-open-protocol> prescription
> of porting as the solution to the problem is, in fact, the specification of
> a HOW. The WHAT is "independence from a platform." There exist a variety of
> means that can be used to provide that quality.
>
> Yes, data portability is one means to reduce dependency on a specific
> platform. However, other means are also available. For instance, if one
> assumed a content-addressable, platform-independent data storage mechanism,
> such as that implemented by IPFS
> <https://en.wikipedia.org/wiki/InterPlanetary_File_System> (The
> Interplanetary File System), then it would be possible to implement much of
> what SocialWeb interactions require without any particular platform.
> Similarly, one could build a messaging infrastructure comprising a mesh of
> publish/subscribe message relays, such as that envisioned by the advocates
> of Nostr <https://nostr.com/>, that would allow the dissemination of
> SocialWeb content without a "platform." (Such a system might be constructed
> by amending the WebSub, or PubSubHubbub, protocol to support AS/AP.) A
> variety of peer-to-peer solutions could also be implemented as alternatives
> to platform-based systems.
>
> While data-portability will solve *some* problems associated with binding
> to a specific SocialWeb platform, it won't solve them all.
>
> The ActivityStreams and ActivityPub protocols, as written, allow for a
> much broader range of communication than can be achieved using most
> commonly used platforms. Given the supported extension mechanisms, the
> SocialWeb protocols support an essentially unlimited range of communication
> patterns. But, because of the way most platforms are implemented, it simply
> isn't possible to benefit from either the breadth or the extensibility of
> those protocols. For instance, one might wish to define an extension to
> AS/AP to support a Chess playing protocol. Unfortunately, for such an
> extension to be useful, it would be necessary to provide not only clients
> that understood the extension but also a server, or platform, that did so.
> And, it would be necessary to convince all who wished to play "SocialWeb
> Chess" to sign into this new server -- whether or not they already had
> accounts with an existing ActivityPub platform. This is because most
> ActivityPub platforms reformat AS/AP content when presenting it via their
> server-client protocols or, even if they don't reformat the data, they
> often filter out objects whose types they don't understand. (e.g. Mastodon
> tries to normalize everything to a Note object.)
>
> I think we should think carefully about what essential services are
> provided by platforms and what might be alternatives to them. Increased
> data portability would certainly be a good thing, but it isn't sufficient.
>

Federated systems by their very nature inherit from the fact that URLs are
stable and gain both reputation, and inbound links over time.  This is an
enormously advantageous architecture for scaling and stability.  The
downside of this architecture, most inevitably, is that moving is much
harder.  You can possibly control outbout links, and internal, but
controlling outbound links is an intractable problem.  This is not a bad
thing, the web is functioning as designed.

Dont make the fediverse do something it cant, or that it wasnt designed to
do.  But use the feature of the fediverse that shines, which is the ability
to add links to systems that can add the features that you want.  This was
generally considered how federated systems would fit into the wider web and
internet as a whole, with the URI being the glue that ties heterogeneous
systems together.  Different schemes have different properties.  The
internet is working as desgined.


>
> bob wyman
>
>
> On Wed, Feb 7, 2024 at 5:08 PM Johannes Ernst <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> 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/>
>>>
>>>
>>>
>>>
>>