Avatar
Stuart Bowman
ff27d01cb1e56fb58580306c7ba76bb037bf211c5b573c56e4e70ca858755af0
Building Satellite https://satellite.earth 🏴
Replying to Avatar Seth

A client you shouldn’t sleep on: https://satellite.earth

nostr:npub1lunaq893u4hmtpvqxpk8hfmtkqmm7ggutdtnc4hyuux2skr4ttcqr827lj is a builder and a true OG in this space 👨‍🚀 (pun intended).

nostr:npub1xxdd8eusvdxmaph3fkuu9x2mymhrcc3ghe2l38zv0l4f4nqp659qskkt7a is cool, but Satellite.earth has range 🛰️

Appreciate it man. It's good to be back

Yep that was a bug sorry! I pushed a fix already but​ make sure you're on the latest version of the app (hold down Shift and refresh or clear your cache) Should work after that.​

Damn yeah that was a bug introduced by the recent localization update!

I just pushed a fix.

If you refresh the app (holding down the Shift key when you click refresh to make sure you get the newest version) and then try to upload something it should be working now.

日本のnostrユーザーの皆さん、こんにちは!

https://satellite.earth を日本語にローカライズしました。おそらく間違いがあると思いますので、もし見つけたらお知らせください、修正します。ありがとう 🙏

Today's the Winter Solstice

That he had to plead guilty because he knew that the law as written would not be respected is perhaps the darkest aspect

The thing about prediction markets is that they don't just reflect direct bets on an outcome.

They also reflect bets on how others will place bets on an outcome.

Once this is understood, they will start to reflect that too.

Deployed Satellite v2.2

- Added support for reading and replying to long form articles

- Added proper link previews

- Bug fixes and performance optimizations

First class support for composing long form is not in this release, but is in the pipeline.

Also I set up a CORS proxy `https://cors.satellite.earth` for link previews. It's really simple, you just `GET /link/:url` and it will proxy the request with the proper headers so your client can parse the response however you want. If anybody wants to use this for your project lmk and I will whitelist your origin.

Got an email saying that Satellite's nostr:npub1getal6ykt05fsz5nqu4uld09nfj3y3qxmv8crys4aeut53unfvlqr80nfm Hub missed a lightning payment because of lack of receiving capacity, yet I have currently have 1.3 million sats of receiving capacity. Smaller payments earlier today went through fine - so either something strange is going on, or someone tried to buy a LOT of Satellite CDN storage...

How though? There are fundamentally only 3 ways right?

1) PoW L1, i.e. a distributed db with public read access and write access mediated by energy with a network effect strong enough that it will never be displaced (so Bitcoin)

2) Make all the data that's being hosted encrypted in equal size indistinguishable chunks so that infra providers can't discriminate even if they want to. (so something like Garland aka the thing nostr:npub1klkk3vrzme455yh9rl2jshq7rc8dpegj3ndf82c3ks2sk40dxt7qulx3vt proposed recently)

3) Pay infra providers enough money that ideology becomes marginalized as a motivating factor as to why the operator would or would not host your data (this is kind of the defacto solution but it fails in cases where the gov mandates censorship)

Out of all these options it seems like #2 is the only one that is actually maybe workable at scale (obv bitcoin works but cannot hold all the state in the world). And *storage* is the relatively easy case. If you want ideology-neutral compute you need homomorphic encryption. (and I guess that's possible but not really fully solved... I don't know enough about that to be sure)

Every time this neutral infra thing comes up in a mainstream forum like hacker news or something, it's clear that the only solution people can agree on is like "the government should force them to be neutral" (lol) I feel like saying yeah maybe that worked in 1996 when the gov was the "containing superstructure" of the world and the internet/media was a like a subsidiary realm, but now that the roles are reversed, well, math to the rescue I guess (why does that sound familiar?)

Not saying a political solution is bad, I'm just saying it's impossible.

Technical solutions are hard, but possible.

nostr:nevent1qgsqddupn4l3cl65wggcyehd009g0pwuatsfudh28f90vewx68vrylqqyz0d2g4d52r5etwuesrmq5tckssac8vtg7p4dwcyglqkaxw7d4lhk8l6jgc

When you read a note from someone you've met in real life, do you read it to yourself in their voice?

Sometimes even when I'm not reading nostr I will suddenly think "swim bladder" in nostr:npub1mygerccwqpzyh9pvp6pv44rskv40zutkfs38t0hqhkvnwlhagp6s3psn5p's voice in my internal monologue

Replying to Avatar Gzuuus

I'm excited to introduce Nostr Social Duck, or just NSD, a library I've been crafting over the last two weekends that brings sophisticated social graph analysis, even to hardware that doesn't have the luxury of abundant memory. This library leverages DuckDB to perform graph operations over Nostr social graphs built from Contact List events (kind 3), and it's designed to run on all sorts of hardware, from low-end devices to powerful servers.

The inspiration came from limitations I encountered with nostr:npub1g53mukxnjkcmr94fhryzkqutdz2ukq4ks0gvy5af25rgmwsl4ngq43drvk excellent nostr-social-graph library. While powerful, loading entire social graphs into memory becomes challenging, specially on resource constrained devices like older computers, mobile devices, Raspberry Pis, and similar environments. Once the graph grows, memory constraints can cause performance issues or outright failures.

The recent launch of Relatr and its inclusion in the Umbrel community store (thanks to nostr:npub1ye5ptcxfyyxl5vjvdjar2ua3f0hynkjzpx552mu5snj3qmx5pzjscpknpr ) got us thinking: how could we enable anyone to run this without being constrained by their hardware? Since disk storage is cheaper than memory, how we can balance the tradeoffs 🤔... That's when DuckDB emerged as the perfect solution

DuckDB is quite a cool piece of software that's been around for some time with an amazing team committed to open source. It's an embedded, in-process database designed to run on all sorts of hardware. What makes DuckDB particularly compelling for our use case are its advanced memory management capabilities. When complex queries require more memory than available, DuckDB automatically spills to disk, ensuring queries complete even if there is not enough memory, rather than crash. No memory, no problem.

This feature alone makes DuckDB a strong choice, but there's more. Its advanced analytic SQL capabilities make graph analysis operations possible and performant. NSD already provides methods to get the shortest distance between pubkeys, along with a complementary method to find the shortest path that returns both the path and distance. You can define a root pubkey which creates a temporary table with all distances precomputed, making subsequent queries much faster.

The library also includes methods for social graph analysis, like, get the degree of a pubkey, how many inbound and outbound connections it has, which helps determine the weight of a pubkey in the graph. There are convenient methods to check if one pubkey follows another or if two pubkeys are mutual follows. As well thanks to DuckDB in the future we could use parquet files to distribute social graph data. You can find all the details in the repo.

We're currently refactoring Relatr to use NSD, and the results are impressive. By replacing the previous combination of nostr-social-graph library and SQLite database with DuckDB and NSD, we've eliminated the inefficiencies of having separate data sources. Complex queries like profile search now benefit from analytical SQL directly in the search algorithm, reducing data transfer between the program and database and returning more relevant results efficiently.

I did some naive benchmarking to understand how it performs compared to the nostr-social-graph library, and it behaves pretty well. Both libraries are pretty close in performance when there's a root pubkey set in NSD.

This effort aligns with the ongoing #WoTathon organized by nostr:npub1healthsx3swcgtknff7zwpg8aj2q7h49zecul5rz490f6z2zp59qnfvp8p , as we believe NSD provides fundamental primitives for performing graph operations on everyone's hardware without sacrificing simplicity of use and deployment.

The library is available now and can be integrated into any js project:

```bash

bun add nostr-social-duck

# or

npm install nostr-social-duck

```

As we finalize the Relatr refactor, we'll share detailed insights about the improvements and performance gains. The combination of Nostr's decentralized social protocol with DuckDB's efficient analytics creates a powerful foundation for the next generation of social applications.

The library's repository: https://github.com/gzuuus/nostr-social-duck

Related DuckDD's blog posts:

- https://duckdb.org/2025/01/17/raspberryi-pi-tpch

- https://duckdb.org/2024/03/29/external-aggregation

- https://duckdb.org/2024/12/06/duckdb-tpch-sf100-on-mobile

If you like the project please consider supporting our work by zapping, or contribute to it's development

This is awesome!

Would love to say it was an original thought but I remember talking with nostr:npub16fhh3ev4gytmt3jn3gkkez9z99kxtspcwupen4cxn2tcym4sd22surn62p at the Riga conf who told me that apparently some bitcoin OG was already blogging about this in like 2012 or something

nostr:note1mm23e5djhpsuhfsr4z6dwhdu8flquag6aj4s8jqx5aecxrjsh4uqrsy7qw