Yes it does. You have a little cake next to your username, kind of the same way as on old Reddit.

There is also the consideration that ATPro has a community that’s both larger and less technical, so it would be harder to move them here than the other way around. I’m thinking the direction to go might be ActivityPub servers that can route things between ATPro personal data stores, but obviously I’m still learning.

There’s been a definite tinge of ideology or at least gatekeeping to some of these responses, but that’s to be expected. FOSS has always had a streak of it.

It’s a bit ironic to use ActivityPub to say ActivityPub has no real applications, though.

Happy cake day!

I mean, it doesn’t have to be part of the standard (it could just as well be Lemmy-specific), but no built-in way to move accounts sucks. AT protocol provides a nice little solution for that.

I didn’t have that one little detail about how demanding a relay is to run. Thankfully, this thread has been illuminating.

It’s still a bummer that Lemmy doesn’t provide any non-hack way to move your account to a new instance.

Ah yes, the wonders of OSS documentation.

Leaving aside all the work they did making an alternative more to their liking, that kind of implies it’s like a light switch, and it’s not.

Yep, probably. People are just going to have to get used to it to certain degree, and to a certain degree there’s going to be .world-type instances that act as a user-friendly default.

There’s other issues at play, of course, which is more why I asked.

Oh? Complicated, fragile, something else?

Yep. What do you think the chances are you could write something that does the job of the router and app view, but in a totally off-standard, more point-to-point way?

In the meanwhile, it’s just a matter of bridging, I guess.

It’s a good blog post, thanks. I made a quick summery elsewhere in the thread.

It’s really unfortunate that we’ve ended up with two populated protocols for federation, both of which have a major flaw. In our case, it’s no established support for moving accounts. In theirs, its a component that’s so bulky the federatability is questionable (and no federated DMs).

Thank you!

TL;DR, the relay bit works as a completely connected network topology, and has the associated quadratic growth issues, which renders it, like you said, hard to host.

Also nasty: Direct messages are just not federated.

Other things are or were at the time of writing janky, but nothing else is quite that egregious. The author is working on a separate project, and recommends this idea as a solution for portable identity on ActivityPub; here’s what “object capability” means in the context.

Bets all in? Okay:

Really? In what way?

Digital identities being cryptographic and independent of any one instance is huge all on it’s own. The rest of it I understand less clearly, but it looks pretty modular.

Yes, do nothing is an option too, of course. When this has come up on Lemmy, it’s usually because there’s an identifiable issue.

Personally, I’m not really in the market to refactor anything right now, this isn’t a practical question. Honestly there’s plenty of FOSS that hasn’t been made the first time.

How would you define “supportable”?

Most Devs hate working on other people’s code though, so prefer rewrites.

I now suspect this is basically where it’s coming from.

Rereading this, I probably should have added a hedge - is it usually better to start from scratch. I do know that there’s exceptions to most rules, and this isn’t actually a practical problem I’m facing.

Thanks, this is kind of how I thought it should be. I just didn’t know if I was missing something, because people on the humour communities trash talk refactoring a lot.

Edit: Wow, Netscape… Sorry to say it, but that post isn’t much younger than me. I don’t even know a most of these examples. That being said, it was still a great read.

So how is that different from refactoring?

Yes, there’s usually a niche case, right? That’s why cargo cult engineering comes nowhere near the real thing.