Probably got your comment in the wrong thread, but that’s just a Lemmy bug. Yeehaw!

There’s many different ways DID could be implemented on top of ActivityPub. I don’t think full content replication (what you’re mentioning) is likely as that’s a fundamentally different style of protocol.

But I can imagine signing in to a different instance with my ID, at which point I subscribe to all my communities from this instance and get notifications if someone replies to one of my comments etc. Just as if I had created an account on this instance and had posted from there. It just means “your” instance can go down and you can continue future interactions mostly uninterrupted from another instance.

YunoHost is a tool which aims to solve the problem of (relatively small scale) self-hosting for people. I use it to host my Mastodon and Lemmy instances and it was very easy. I haven’t dealt with email but that’s also something it supports.

It’s a pretty great platform, although unfortunately it’s currently unable to upgrade Lemmy past 0.16.7 which is a bit of a pain… So it’s hard to recommend it for Lemmy right now.

100% agreed with both. Especially DIDs just need to happen on all ActivityPub platforms. It will not only free users from being locked to an instance, but it will also allow instances to be much more flexible in scaling their capacity. Lemmy.ml is overloaded because they have too many users, and anyone who signed up there can no longer use their account. DID would allow them to immediately use their account from any small or large instance with spare capacity without changing the experience. The same would go for Mastodon.

Beehaw only defederated from Lemmy.world because of the currently limited moderation tools in the software. This is not going to be a problem forever.

I hope people can find communities both on large instances (Beehaw, Lemmy.world) as well on as very small niche instances. Discoverability is a bit a problem but I think over time we will find communities we like, and participate in them. What instance they are hosted on is not all that important.

Huh. Guess I won’t be using Uber’s apps then. Anytime I’m a paying customer I do not want to see ads shoved in my face. Good thing there’s competition.

Both Breath of the Wild and Tears of the Kingdom have fantastic sound design. The environmental sounds of wind, water, trees and wildlife accompanied by that understated soundtrack makes you feel out in the wilds even though the graphics are minimal.

Hey Chris. Seeing more and more people from my Mastodon feed here :)

I’m very impressed by Lemmy. Some of the communities like Beehaw have been excellent, even before the recent Reddit API-apocalypse. Self-hosting has been a bit challenging compared to the more mature (I guess) Mastodon but I hope to get it sorted out soon.

A really good artist who’s been on Fedi far longer than most.

David Revoy’s take on the Reddit situation: https://framapiaf.org/@davidrevoy/110532791930270318

Death’s Door

The first try blindfolded Guardian parry made my jaw drop. I struggle timing that even when I can see them.

I’m still a bit sad about Reddit’s seemingly approaching ending. I never cared about Twitter so moving to Mastodon was a snap, but Reddit has had loads of amazing content posted and I’ve enjoyed it for 15+ years. I love the Fediverse, and Lemmy is great, but it may take some time before these platforms and communities can replace Reddit for me.

Zelda?

Spam on Fedi is @-ing people and sending the message to their instances. Unless an automated system rejects these messages before delivery, the user will get an notification. Just like email.

Email does Sender Verification too. And in the case of Fedi it just means there must be an account at the sender’s domain. It doesn’t have to be human. And as long as the spammers can keep generating domains they can keep sending spam…

You don’t need an exploit to send spam however. Anyone can currently write a client which posts spam messages to an ActivityPub instance. It is a weakness of any open federated service. The alternative would be a closed system where moderators would first have to approve any instance federation, but that’d be a very different and insular Fediverse…

I think ultimately we’ll end up with very Email-like mitigations. Blacklists (spamhaus), message content heuristics, sender verification, etc.

Something to consider with regards to spam is this: The Fediverse works very similar to email. Spam has never been solved for email, even after decades of trying all sorts of ever more complicated mechanisms. I expect it to become an equally painful and challenging problem for Fedi.

Sure. I’m a big fan of federation. However, I switched to Mastodon (the ActivityPub application) because I liked its style better than Twitter. Turning Mastodon into Twitter to attract a larger audience and placate the complainers isn’t necessarily what everyone wants. Just my personal view on this. But it honestly doesn’t bother me that much.

The signup/moderation issue feels somewhat similar. Yeah, it would be way more Twitter-like if signup defaulted to Mastodon.social and that mega-instance hired a content moderation team to rival a professional social media site. But that’s not quite what I think is currently good about Mastodon and Fedi…

Good post. On the other hand, IMHO (as a non-Fedi-expert I should say), I think the Fediverse does not absolutely need to appeal to everyone. A lot of people are happy with Twitter, and a lot of people are happy with Facebook. Evolving Mastodon into a clone of Twitter is perhaps missing the point of building a different platform in the first place. Not to say there’s no place for new ideas or criticism of course…

To add after reading the post again: A centralized social media site with a professional content moderation team is, of course, always going to provide a better experience to new users. I don’t think a decentralized platform will ever be able to compete, by design. “Full text search” and “quote posts” are not going to help when someone accidentally joins a poorly moderated instance.