Right now blacksky.community is an app that uses Bluesky’s AppView, which in turn uses Bluesky’s Relay. They’re working on their own AppView (which will have the equivalent of local-only posts) and that will use their Relay.

Interesting, from what I understand of ATProto, this would be hard to do on protocol, it’ll be fascinating to see how they do it. Maybe something off protocol like the recent bookmark feature Bluesky got.

I didn’t mean to undercut your point though, they often talk about PDSs as analogous to web pages, so your “different search engines” analogy is very accurate, it’s just not quite there yet.

I’d love to take credit for this, but the ATProto docs themselves make this comparison which is where I’m getting this from.

if I recall correctly either in (((streams))) or Forte (or maybe both) MIke implemented the nomadic identity over ActivityPub as well

This sent me down a bit a of a rabbit hole. It seems (streams) used an updated version of Zot, Zot/11 but was renamed to just Nomad. I can’t find anything about this, the (streams) repo only contains the spec for Zot/6, so I’m not sure about it’s APub compatibility. Apparently, Nomad had been discontinued in Forte in favour of pure APub, anyway.

If you’re thinking about this kind of stuff for Lemmy, it’s also worth looking at https://socialhub.activitypub.rocks/t/fep-ef61-portable-objects/3738

Oh, I know about Silverpill’s work, it’s really interesting! I even mentioned it recently. I’m glad we have someone smart like them working on this stuff.

I do think some kind of separation of user data from servers, like what AT Proto does, is actually quite desirable. I just don’t like that PDSes can have their data harvested by whoever, I think data sharing with a server should be opt-in.

Oh, I thought blacksky.comnunity used Blacksky’s relay. If it uses Bluesky’s then yeah, disregard what I said.

That’s not a perfect analogy though because Blacksky makes different moderation decisions than Bluesky.

I’d hope so given how abysmal Bluesky’s moderation is. The discovery feed is filled with transphobia, but you can’t say Charlie Kirk should rest in piss.

Again though it’s not a perfect analogy because the AT Protocol architecture lets you migrate all your data between PDSs seamlessly, and so far only a few niche ActivityPub implementations support that (Hubzilla et al with nomadic identity, ActivityPods using Solid Pods).

I don’t believe Hubzilla’s nomatic identity works with APub though, irrc it uses something called Zot.

I’ve been thinking about how to add nomatic identity to Lemmy quite a bit and it’s something I’d like to work on after 1.0 is out, but it’s hard a problem for sure.

A better analogy would probably saying it’s like Bing/Google. They’re independent of each other but broadly what’s on one is on the other.

independent but still connected (think about Lemmy instances)

It’s not really connected in the same sense two Lemmy instances are connected. They’re able to pull in the same data as Bluesky as it’s all public and PDSs don’t really have the ability to block a relay from crawling them.

The discourse around decentralisation has elevated a form of network architecture that facilitates and contributes to a healthier social internet into a goal into itself.

Big agree with this.

That doesn’t feel like how search should work. It should be ranking results that fit the search query better higher than ones that fit it less.

But the existing filters already prescribe an order outside of how closely the search term matches, you brought up top month and I don’t see how you’d want that to work other than a binary filter sorted by votes.

What you’re describing would be a new sort order, analogous to Reddit’s ‘Relevance’ sort. It’s certainly doable with postgres’ builtin distancing operators, though it be slower.

I wonder what objections there could to the statement other than procedural. It’s a nice ‘let’s work on making stuff better rather than fighting with each other’ message.

This from @mackuba@martianbase.net is good and up-to-date: https://mackuba.eu/2025/08/20/introduction-to-atproto/

And the fact that AT Proto requires the full firehouse replicated to all relays.

It doesn’t, not even Bluesky runs a full network archive relay anymore because it proved to be too complicated and expensive.

Unless I’m missing something in the code I linked, they’re not. All that action does is merge one community into another on the local database, nothing federates.

As for why Piefed and not Lemmy, it’s because Piefed communities are portable. That is, if the admin proves to be awful or a server threatens to shut down, you can just move the community elsewhere.

Are they? The only thing I’ve heard about this is Piefed’s community move admin action, which is just a simple db rewrite only on the local instance.

This doesn’t have anything to do with sort ordering though, which is based on time and votes. Text search is just a filter on top of sorting.

You want exact word matches prioritised ahead of entirely unrelated words that include the same characters. Like “enum” should turn up your comment, but rank a comment that contains the text “renumbers” much more lowly. A particularly smart search page might keep “enumerate” high while rejecting “renumbers”, though.

Of course, it’s true that at least in the current latest release, Lemmy fails at all of this. I hope 1.0 is at least fixing some of it?

How Lemmy does text search is via pg_trgm which works by breaking down both the content text and search text into trigram* and if the content contains enough of the search trigrams, it’s considered to match the search term.

* A trigram is just a 3 character ‘words’, for example the trigram of ‘enum’ is {" e"," en",enu,num,"um "}.

What you’re describing is closer to a tsvector, so you could open up an issues on Lemmy’s GitHub to move from trigram to tsvector. One advantage trigrams have though is that they’re language agnostic while tsvectoss need both a dictionary and to know the language (thankfully, Lemmy already has this info via the language setting, though the way it’s stored will need to be changed to accommodate this). But tsvectors does provide much more intuitive language matching, like what you outlined.

Eh, I don’t think it’s that surprising. Getting a list of comments on a post vs getting them from a search term are very similar operations, so it doesn’t make too much sense for these to have different queries in the backend. One thing you could do, but no client to my knowledge does, is add a search bar to a post that searches through the comments only within that thread.

Everything in the backend uses the same sorting as the posts do on that page except comments, which is frustrating. Comments do need a different sort enum as there are some options that don’t apply to comments (scaled, new comments, etc.), but yeah the fact the top options don’t work for comment search when they should is opaque and not user friendly.

I can’t wait for 1.0 to actually come out because I feel like a broken record, but this is fixed there.

Ah, right comments don’t actually top with time ranges in 0.19: https://join-lemmy.org/docs/users/03-votes-and-ranking.html#sorting-comments, my bad. The fact lemmy-ui still shows all of them is very confusing, I’ll admit.

This is different in 1.0, the logic was changed for both posts and comments so these will work in future.

Doing it this way is why small instances gets hammered when a user’s post goes viral.

Setting up caching in the reverse proxy layer would alleviate this a lot of this. Like, GoToSocial only recommends to set up caching for the key and webfinger endpoints, where having it set up to cache posts and profiles for like 60 seconds (or however long the Cache-Control header says, Mastodon defaults to 180s) would alleviate the strain on the server so much.

There are other thing you can do, like this post explains some other things for Misskey, but the defaults should be sensible so you don’t have to be a sysadmin expert to host an instance and they’re currently not. I host 2 Lemmy instances (ukfli.uk and sappho.social) from a £5/month VPS and they’re able to handle bursts of hundreds of requests without issue.

Bluesky is built to assume a handful of big relay (remember that a relay can merge in contents of another) and a bunch of appview and a ton of PDS servers, feed generators, moderation labelers, etc.

People are already building small, non-archival relays so this assumption seems mute. It’s also important to remember that relays are an optimisation, not a core part of the protocol.

I mean, this would become less trivial the more replays go into use, where to get a full view you’d have to pull from all the relays that exist.

ActivityPub’s solution to this is just IMO better, the original post has a replies collection attached to it that acts as the authority the replies the post has. This also allows creators to eject replies from the collection. There are issues with the way fedi software currently handles fetching from these reply collections, but the missing replies thing is very solvable in ActivityPub.

If your idea is that the replies to every post look the same to any user, anywhere, at any time

This is only true of Bluesky because everyone is using Bluesky’s infrastructure at the moment. If Bluesky ever deindexes someone and they start posting to an alternative relay, you suddenly don’t have a guarantee of a full view of a post’s replies.

They even had a banner on the site for a little bit about how successful they were able to transfer support from Patreon:

https://web.archive.org/web/20250610153337/https://catbox.moe/

Real Account Portability: Move your entire account – posts, comments, followers – to any new instance seamlessly. Your identity travels with you.

This is nice in theory but comes with edge cases that are hard to account for. Like, what if you have a post and your new instance defeds the instance the post’s community is on? You either have to allow banned content onto the instance or the user loses data, neither of which are acceptable.

This is part of why ATProto’s decoupling of user data from app logic is kinda genius and the direction we should go in if we want portable actors in Lemmy/thredi.

Full Fediverse Compatibility: We can add DIDs to Lemmy while staying fully interoperable with Mastodon, Kbin, and all other ActivityPub platforms. No breaking changes, just a powerful upgrade.

Not really, every fediverse platform that people use expects an Object’s id to be a https URI it can just fetch the resource from. This is part of why FEP-ef61 specifies a way of translating a DID to a https URI. That’s not to mention that moving existing actors from their current ID to a DID will cause all sorts of interop problems.

Edit: Also, is this AI-generated? It has all the tells of Gemini output, especially the the issue on Github.

Oh, within a multicomm. That makes sense now I think about it.