Post by @movim@piaille.fr

RE: https://masto.es/@andrewblasco/117116298104503847

That's why having a protocol where the clients are separated from the data is important. ✨

If your interactions between your clients and your account is standardized you can easily switch clients and import/export your data.

With #XMPP you only have one account (that you can host yourself) and many clients that allows you to do chat, social networking, video-conferencing ...all synchronized together. 😸

If tomorrow you want to switch to another Movim instance or another XMPP social client, you just have to login on the new one with your existing account!

Riquiñez :linuxmint:

@andrewblasco@masto.es 2 days ago

Attention please! (Clears his throat).

Seeing that the Pixelfed.social server was receiving spam and scam accounts, I decided to switch server. Imagine my surprise when I discovered... I couldn't. You can't migrate a Pixelfed.social profile to another instance. Apparently, this has been the case for over a year, by other complaints I've seen.

The lead developer has said something like they're working on fixing it, but it's been like this for a while...

I asked @pixelfed for an explanation several days ago. They've posted things, but they haven't answered to me.

Meanwhile, they've disabled one of the main features of the Fediverse on the largest (and "official") #Pixelfed server.

In other words, they're holding all their users hostage, which goes against the philosophy of the #Fediverse.

What's more, Pixelfed has a function to export your data. However, exporting posts always fails.

I thought, well, at least I can import the people I follow. Nope, because the only import tool they've designed is one for importing your Instagram account. Disabled on the main Pixelfed.social server, by the way.

I even started to think it was because they were one version behind the server I wanted to move to (which would be strange, since it's the main server).

Well, no, they have the same version. But you can only migrate your account INTO Pixelfed.social, not the other way, OUT of Pixelfed.social. That makes the whole thing crystal clear to me.

In short: NEVER create an account on Pixelfed.social, or you'll be held hostage. I recommend another servers (Luzeed, Fotolibre, for example). And there's also @vernissage for sharing photos.

You can all follow me again at this account: @andrewblasco@luzeed.org. Because of course, without account migration, you lose all your followers 🤷🏽‍♂️

#xmpp

12 Replies

0 Boosts

Daniel Gultsch

@daniel@gultsch.social 5 hr. ago

@movim From my understanding of the original post they probably need something like XEP-0283: Moved, which is not super widely deployed in the XMPP ecosystem (yet). But yes, the fact that almost every Fediverse client has a task-specific backend is something I find weird and a bit annoying too. Especially, but not just, because it forces me to have different identities. (One for micro blogging, one for videos, …)

mario

@mario@snac.sabatino.cloud 5 hr. ago

@daniel@gultsch.social @movim@piaille.fr what I write is not related to xmpp but #ATproto is good for that and better than #activitypub imho. You have one PDS (personal data server that can be also self hosted) and several apps who retrieve data from the PDS.

Daniel Gultsch

@daniel@gultsch.social 5 hr. ago

@mario @movim Yes, when describing the status quo #ATproto is better in that regard (relative agnostic PDS with different 'views' on to the data). However I think that’s not necessarily inherent to #ActivityPub. It’s just how most (or basically all tbh) implementations work right now.

marius

@mariusor@metalhead.club 5 hr. ago

@daniel indeed, ActivityPub supports an independent PDS like server but most of the popular services are not designed like that. I think ATProto PDSes are a bit more versatile, as they support storing opaque binary blobs, where ActivityPub requires compatible JSON-LD documents, but there's definitely the possibility of "owning" your data.

@mario @movim

Daniel Gultsch

@daniel@gultsch.social 5 hr. ago

@movim That said I listened to a presentation about #ActivityPub C2S by @django at #FOSSY and his efforts to create a general purpose client, which I guess would eventually also open the door to generic, frontend agnostic servers as well.

I guess the way it works right now is mostly for historical reason; That’s how #Mastodon did it and everyone followed. But it doesn’t have to be that way for ever.

silverpill

@silverpill@mitra.social 3 hr. ago

@daniel @movim @django This is not because of Mastodon - ActivityPub is simply not designed for generic servers.

However, generic servers might become possible after making some adjustments to the protocol:

https://codeberg.org/fediverse/fep/src/branch/main/fep/fc48/fep-fc48.md

Codeberg.org

fep/fep/fc48/fep-fc48.md at main

fep - Fediverse Enhancement Proposals

silverpill

@silverpill@mitra.social 3 hr. ago

@daniel @movim @django This is not because of Mastodon - ActivityPub is simply not designed for generic servers.

However, generic servers might become possible after making some adjustments to the protocol:

https://codeberg.org/fediverse/fep/src/branch/main/fep/fc48/fep-fc48.md

Codeberg.org

fep/fep/fc48/fep-fc48.md at main

fep - Fediverse Enhancement Proposals

marius

@mariusor@metalhead.club 2 hr. ago

> ActivityPub is simply not designed for generic servers.

@silverpill you're overthinking it. Of course they're possible to do at the same level as PDS's are. Storing the JSON-LD as an opaque blob after the server handled what it understands from it is the obvious solution.

Maybe you mean that generic clients might be difficult to implement - which I bet is the case for every dynamic protocol ever, including XMPP and ATProto.

@daniel @movim @django

3 more replies

Movim

@movim@piaille.fr 5 hr. ago

@daniel @django Oh that's nice indeed, so it's not by design. That would be great if they are going there, especially for bridging XMPP with ActivityPub 😊

Happy to read that.

Movim

@movim@piaille.fr 5 hr. ago

@daniel From what I saw from the ActivityPub ecosystem is that each client is kinda building on top of the base protocol where in XMPP we try to create generic concept.

For example a Story in XMPP is a simple Atom item published to a dedicated Stories node on the user account https://xmpp.org/extensions/xep-0501.html .

So if a client want to do Stories it just have to parse and publish to this node, where in ActivityPub you are more trying to integrate with Mastodon, PixelFed, PeerTube... directly.

XEP-0501: Pubsub Stories

This specification defines a way of publishing Stories over XMPP.

Daniel Gultsch

@daniel@gultsch.social 5 hr. ago

@movim No, you are 100% correct and I agree with you. I’m just not sure that this is what @andrewblasco was complaining about. 😄

And we should look more into XEP-0283: Moved. There was a talk at #FOSSY about a large XMPP provider going down and the problems that cause which reignited my interest in account migration.

Riquiñez :linuxmint:

@andrewblasco@masto.es 3 hr. ago

@daniel @movim Well, in fact, nothing of this would be a problem if Pixelfed developer supported the standard migration tool at ActivityPub.

The protocol and tools exist (could improve, but exist).