dboft runs on two Rust programs named after weaving. loom is the interface: like the machine that weaves many threads into one cloth, it gathers conversations from dboft and across the fediverse into one readable site. weft is the server underneath: named for the thread a loom carries across, it stores the posts and comments and trades them with other servers over ActivityPub, the fediverse’s open standard. It also speaks Lemmy’s API, so Lemmy apps work with it. To find related posts, loom turns every post and comment into an embedding: a small open model, Qwen3-Embedding-0.6B running on an ordinary CPU, maps the text to 1,024 numbers that capture what it’s about. These are stored in PostgreSQL with pgvector, and an index finds each story’s nearest neighbours in meaning in under a millisecond, even when they share no words. Its just an experiment.

an embedding

I was not aware of this technique. Very interesting.

It’s interesting... The neat part is that “a dog chased a ball” and “puppy playing fetch” end up close together even though they share no words, so related posts turn up without any tagging. It’s the same idea behind a lot of semantic search, and small models like this run fine on an ordinary CPU... so giving it a shot here to see if it adds any value.

Do you have any suggestions for research papers or other references to learn about that technique?

I actually learned this from a few YouTube videos a long time ago rather than papers. Let me see if I can dig them up for you tomorrow. I’m sure there are people here far more educated in this space than me, so if anyone has better references, please jump in. !remindme 12h Dig through my youtube history for embedding videos

Thanks in advance!

Could not find them ... but, I found this one by freeCodeCamp.org easy to follow https://www.youtube.com/watch?v=yfHHvmaMkcA

I remember trying out a fediverse mobile client called Loom. It has since been taken off of testflight on IOS. I wonder if it was the same thing. The UI does look similar. It looks great! It would be amaz if it can be optimized for desktop too.

That wasn't this but I will look for that name... dont want to step on anyones toes. And you should look at this on desktop and I'd love feedback. I made it more like an email client with multiple columns.

Oh it was probably a different thing maybe, but it had the same concept of creating custom feeds hence being called Loom.

I haven’t had the chance to check it on desktop yet, but if it has columns, I’m sold! My pet peeve with most frontends is that they waste space on desktop. That’s why I’ve been using voyager because it has a 2-column layout option that sorta uses more screen real estate. I’ll definitely check it out on desktop asap!

I’d prefer if Piefed was the standard for the API but I’m assuming you did that because PieFed has more features and therefor would have been more work?

I think most Lemmy apps are either compatible with both Piefed and Lemmy, or just Lemmy. So putting out information in a Lemmy format will let more clients connect to it?

That’s very cool, and I appreciate the thought that you’ve put into this, including the naming.

How does the embedding side change as it scales up? (Storage costs and performance). Brainstorming based on your description, I assume the embedding process is the most resource intensive, and lookups are basically free? If so, would the limit be how fast it can process all new posts?

I wonder if it would be helpful to run a threadiverse search service like this, which other instances can plug in to. Theres no strong reason for everyone to run their own, since they can just filter out any results that a particular instance has blocked or banned. In our case, we wouldn’t want to replicate that work across the few instances that we run.

Pretty much, yes. Embedding a post takes about half a second on dboft's small server, and the lookup afterwards is under a millisecond. At 3–4 thousand new posts and comments a day that's maybe 40 minutes of work, so the ceiling is exactly what you guessed: how fast new posts can be embedded. More cores or a small GPU would push it way out i would think. Storage grows too, about 14 KB per post with its index, so 35k today is ~500 MB and a million would be ~14 GB. It all lives on disk in Postgres; keeping the index in RAM just makes lookups sub-millisecond instead of a few milliseconds, and Postgres caches the busy parts on its own, so it degrades gently rather than falling over. This was just an idea; I'm just putting it into together to see if it holds up. I like the idea of a shared service... I wonder what the memory constraints would be at scale.

Cool!