flamingos

How they see it: https://sfba.social/@otters_raft@lemmy.ca/115267196743748430

Do note that Mastodon forces a redirect to the original instance for non-local posts, here's a direct link to the comment: https://sfba.social/@karlauerbach/115267230182946226

It seems that threadiverse posts are being seen by more mastodon users now, which is great, but maybe the formatting could use some improvements?

There's actually some related (yet-to-be-merged) changes to this on the Mastodon side, add support for links in Attachments (this is how Lemmy and the like federate links).

I don't think anything's changed, just two users finding a post in a hashtag (Lemmy adds the community name as a hastag for posts). I've seen some masto users complain about this in the past on the #lemmy tag.

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.

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.