Skull giver

It can work for other use cases Lemmy is proof of that. However, it’s not the main objective to be a federated Reddit.

Lemmy, Mastodon, Pixelfed, WordPress, Friendica, and Mobilzon all have different design considerations that are all equally valid. Some of the edge cases necessary to make Lemmy work well are unnecessary or even unwelcome for other designs (see: following Lemmy communities turning your timeline into an endless stream of boosted replies).

ActivityPub isn’t magic. It’s very deliberate in its push-based one-on-one entity relations (for performance reasons mostly). For social media, that works fine. The problem comes in when you get massive communities all posting in single threads, or people with thousands of followers that don’t know about each other rather than a friend group interacting with each other. Mastodon absolutely sucks for people with a large following; this isn’t something that’s unfixable, but fixes do need work and deliberation to work well.

I’d say ActivityPub works great for most social media. The biggest exception may be chat (DMs are footguns that work almost accidentally) and ranked-score forums like Reddit, which require a lot more post-processing than other social media protocols.

It should also be said that both Lemmy and Mastodon use the ActivityPub spec mostly correctly (neither is fully spec compliant as far as I know), despite using different mechanisms to achieve the same goal that aren’t always compatible. We can barely get chat apps to interoperate, it’s impressive how well ActivityPub has proven to be.

I don’t think the situation would be very different had Lemmy been based on ATProto or Nostr. Reddit is a bit of an odd duck in the social media landscape, and very few other websites share its core patterns and algorithms.

The way you describe this, it sounds like it would need to work on trust a lot more than it already does. What if there’s a malicious instance actively circumventing bans, ignoring any pulbished banlist?

They already exist with the current Lemmy model, unfortunately. Bypassing ban lists isn’t exactly difficult unless the server you’re following does whitelisted federation.

I was talking about the scenario where you are instance A and you don’t know the followers of a user of instance B. That is not easy to keep track of, since you obviously don’t get any of the follow requests for a user on another instance.

If you don’t know who’s following who, ActivityPub still has inboxes and other collections that can contain existing posts for new servers. Server A can add their likes to the appropriate collection and any new servers can fetch that collection at the first follow of that account.

Agreed. I think that’s a shortcoming of ActivityPub.

ActivityPub has been designed as a push-only protocol as push/pull would involve too many web requests. It was designed for designs like Facebook and Twitter. This flexibility made Lemmy possible.

As for sending the post, it’s not that hard to keep track of all servers that follow a group or person or hashtag. Following people is not passive, you send a follow request which usually gets approved automatically.

Bans are already questionable. Servers choose not to forward every message (personal, group, public) to every account. There is no “themselves” in a shared server. Either the entire server gets banned, or the server is trusted to enforce bans. Lemmy federates those bans (though Lemmy and Kbin don’t always communicate right).

What if the community defederates an instance but my instance doesn’t defederate that one - will my instance send the post to the instance that is defederated by the community?

I would say “the server publishes a banlist containing *@bad-server.tld”. The defederation list on Lemmy is public anyway, but you could also argue for making such behaviour a setting, and there are probably other/better alternatives.

Lemmy doesn’t do it currently. It blindly trusts communities to not lie to people. I just found out about this myself.

In theory the JSON body could include all the necessary information to validate a signature and the signature itself. Then, a simple HEAD request could validate the contents without having to re-download everything, and users’ public keys could be cached to minimise HTTP requests necessary.

ActivityPub was designed for social networks, not for forums. I’m not surprised it doesn’t work well for Lemmy.

The alternative, in my opinion, would be shared inboxes combined with adding the “public” audience to outbound messages.

I’m not sure if that’s true. From the spec:

Additionally, if an object is addressed to the Public special collection, a server MAY deliver that object to all known sharedInbox endpoints on the network.

This requires implementing sharedInbox support, but I believe this should permit federating any content of choice to any server.

But surely the receiving server could validate that signature by verifying the existence of the received activity (by asking the origin server for the object referenced and validating the signature).

If like objects are distributed in URL form, this is already how it works. The extra load wouldn’t be fun, for sure, but the lack of an embedded signature makes it very easy to falsify anything on the Fediverse.

But that’s how ActivityPub was designed? Are groups going to be implemented in Mastodon by replicating the crazy “pretend there’s an account boosting everything that’s happening on the server” behaviour?

I mean, you can run your own frontend if you want to? If you can run a backend, you can run a frontend. You can’t get away with hosting a relay or an app view, though, you need to host a full personal data server, with your own indexers and everything. You can also rely on external indexing, but then you turn dependent on the servers you interact with.

As for federation, you can federate with smaller services just fine, but Bluesky’s design makes it very centralised around the main server. There’s nothing on the protocol level that enforces federation with the main site.

This is a bit like with the Fediverse: for a couple of years, the only relevant service on there was Mastodon, specifically a few larger Mastodon servers. If you didn’t federate with them, you may as well not have federated at all. This also made some of Mastodon’s weird quirks de facto standards for Fediverse support (like how some ActivityPub object types aren’t supported, and people put every huge web page in a “post” object so it would be rendered by Mastodon).

If the main Bluesky server bans you, there’s nothing preventing other Bluesky instances from indexing your content just as easily.

If anything, this setup allows for more freedom than (for instance) Lemmy does. If Lemmy.world bans you, you can’t post in their communities anymore. Other servers can’t discover your attempts to post, so your local posts will remain local, out of reach of any ActivityPub server. Sure someone could scan the Lemmy API for differing posts, but that’s not how Federation is implemented here.

On Bluesky, independent servers can (should) index each other using the standard API. You can get banned from bsky.app, but other servers can still see your posts pop up in their feed.

I don’t know for sure how banning works on a technical level, but it is my understanding that moderation on Bluesky is actually done not dissimilarly to nostr. Everything gets processed and stored, but there’s a layer between the database and the frontends that handles blocking and banning. Of course Bluesky could disable federation with your server entirely, but it seems to me like they’d still federate your content even if your account is banned using normal banning tools, unless other servers propagate your ban as well. That’s up to them to decide. This too is unlike ActivityPub, where an account ban will also halt propagation.

From what I can tell, it’s perfectly possible to set up an independent Bluesky network. The only issue is that Bluesky users don’t give a shit about federation and won’t move to any alternative server, so if you want to reach them, you need to play nice with the main instance.

That’s a load-bearing “could” if I’ve ever seen one.

I don’t really see the point of these new authentication methods. OpenID had federated authentication years ago that was actually used by a bunch of sites like stackoverflow. Native browser support is nice (as long as browser addons can be used to manage credentials) but I don’t really see that big an advantage to good ol’ OpenID.

OpenID died in the federated space because developers couldn’t be bothered to trust anyone but Google, Facebook, and Twitter, so I’m not sure why things would change now, unless the big auth providers shut down their OAuth APIs in favour of fedcm.

Lemmy is search indexable. It includes the necessary metadata headers to link back to original domains as well, something other ActivityPub implementations forgot.

The user base on Lemmy is tiny compared to Reddit, though. Same with Mastodon vs Twitter. The problem isn’t search indexing, it’s the user base being several orders of magnitude smaller.

If you search for topics where Lemmy has a lot of posts (Linux distros, for instance), you can already find Lemmy in the search results every now and then.

Can one even take advantage of a machine? Data’s personhood wasn’t established at that point in the show, mostly because the episode was ripped from a cancelled earlier attempt to revive Star Trek.

Link detection is flaky as hell, especially for special characters. They rarely work reliably. URLs themselves don’t contain unicode. They use basic ASCII and anything beyond that needs to be encoded in some form. The link you posted isn’t a spec-compliant link, it only works because Lemmy apps and browsers are nice and do the conversion to the real URL for you. According to the spec:

When a new URI scheme defines a component that represents textual data consisting of characters from the Universal Character Set [UCS], the data should first be encoded as octets according to the UTF-8 character encoding [STD63]; then only those octets that do not correspond to characters in the unreserved set should be percent- encoded. For example, the character A would be represented as “A”, the character LATIN CAPITAL LETTER A WITH GRAVE would be represented as “%C3%80”, and the character KATAKANA LETTER A would be represented as “%E3%82%A2”.

If you use usernames as identifiers (which, again, are optional) like Lemmy does, databases and external entities will use the percentage URLs, not the readable ones. Unicode domains will have their xn-- form stored as well. It’s up to apps and browsers to decide those and turn them back into unicode. It’s not really relevant what apps and browsers show you when it comes to the technical interoperability of users.

ActivityPub itself has wide support for various languages, including having different names and content for different languages. The username (actually preferredUsername) is transmitted through JSON, which is by definition UTF-8, so most encodings in use today (not that weird Japanese one and that other Asian encoding that’s not UTF compatible) will Just Work™ assuming the necessary URL encoding and decoding logic is added in the right places.

I think Lemmy can be patched to accept unicode characters as usernames, as the current limitations in code and in the UI are just choices made during development. I don’t think it’ll add much, though.

Looks good because URL beautifiers catch that, but the actual URL you linked is https://ar.m.wikisource.org/wiki/تفسير_ابن_كثير and relying on URL detection has proven to be very unreliable. For instance, Wikipedia links often lack closing parentheses, or closing parentheses and other punctuation get added to links accidentally.

Hex-encoded URLs are technically valid, but not very readable to humans.

ActivityPub users need to be identified by some identifier in the URL, and Lemmy chose the user name to be that identifier. As a result, non-Latin usernames become… complicated. Just the right-to-left nature of scripts like Arabic alone would break UI design. Technically you could hex encode usernames and assume them to be UTF-8, but it’d be a massive pain that’ll undoubtedly break compatibility with other services.

You can use your display name to freely enter just about any name. Usernames are almost entirely irrelevant to Lemmy as far as I’m aware; I think they only matter in mentions (although that’s a choice as well, on the ActivityPub level there’s no need to do that). The display name should cover the “it looks really cool” component. As you’ve maybe seen already, you can include names, flags, and emoji in there as well!

With the current username system, there are more possible usernames than there are grains of sand on earth, per server. I don’t think we need a bigger username pool. We may need a better way to tag people, though, but that’s also true without different character sets.

What was the political implication of Data having sex with Yarr while she was under the influence? Something about the people willingly getting fucked by those outside their sphere of propaganda spread by unrelated outside forces?

Some Swedish supermarket, I believe: https://handla.ica.se/produkt/1323024

Related products include Ben&Jerry’s, so I guess this is the frozen form. I can’t find a search bar on the website, though, so I don’t know if there’s a DIY version.

Everyone knows blood for eating doesn’t come in bags.

It comes in plastic containers.

I understand that. But those rules are also making people give up on contributing to the kernel. When I put code out in the open for others to take advantage of as they wish, I don’t feel like adjusting my work to other people’s standards so that they can use my code.

Valve contributed to Linux before, so the fact that they don’t have any direct upstreaming plans right now indicates that something is causing friction.