Nostr Web Client

windows patches are welcome. Right now i just have the data structure that I’ve already mapped to data types within Swift/damus. The lmdb bit is coming soon.

Pedro Vicente 2y ago

Here you go. Started with just a CMake script that defines a library used by ‘test’ and ‘bench’. Tested in Linux and made a pull request. The ‘test’ program fails with an assertion by the way. CMake is just a must have build tool for cross compiling https://github.com/damus-io/nostrdb/pull/1

Replying to

jb55

Damus used to run on sqlite but it couldn’t handle the load, even with optimized queries. lmdb is the only thing that doesn’t fall over atm.

Pedro Vicente 2y ago

Got it. I just created a fork of your new database and will try to do that CMake build and Windows port soon. Curious about the performance, and it seems so simple (I like simple things). Cheers. https://github.com/pedro-vicente/nostrdb

Replying to

cloud fodder

Tho ya you also will have to export and import the db.. which I imagine will take a while on damus.. so not the easiest upgrade to pull off.. you can do it with minimal downtime by starting the new version side by side and running an initial export, then importing to the new while the old one runs, and then running a stream to catch up .. but yea, all very time consuming heh. 🤙

Pedro Vicente 2y ago

The strfry database seems super complex. Why just not go with a “conventional” DB, like SQLite, or SQL server (with ODBC connection)? Me, I use a JSON array of Nostr events as “database”, with linear search :-) . This is a database with one record. Simple (also happens to be my first ever Nostr post) https://github.com/pedro-vicente/nostr_client_relay/blob/main/database/database.json

Replying to

jack

nostr has its issues. but for those who figure it out, it’s the most powerful network that exists today. challenge is helping more people figure it out.

likely most of that won’t come from social use cases, but rather the microapps that #[0] originally envisioned and folks like #[1] are focused on building.

the power of this thing is the ecosystem part. it’s permission-less, meaning anyone can build whatever they want, and it has a permission-less global payment system readily available through bitcoin. but neither will sell people on joining it.

if the apps built on top of nostr do valuable things, like https://highlighter.com does, then every nostr app and use case benefits, including the social clients.

this is going to be a long road, but one that fundamentally changes the way people experience the internet. if it doesn’t succeed itself, it will certainly inspire the thing that does.

Pedro Vicente 2y ago

💯

Replying to

jb55

gm nostr. what’s the plan today.

Pedro Vicente 2y ago

Build an iOS client 😶

Replying to

ODELL

good morning nostr, we must build the future we wish to see 🫡

Pedro Vicente 2y ago

🫡

Replying to

CARLA⚡️

As someone also on Twitter, #Bluesky, and threads, I can honestly say #nostr is the only place I’m unapologetically myself.

Anything goes. Stream of consciousness notes? You betcha. Dog pics? Obviously. Beautiful AND ugly feet, sned ‘em. Hot selfies or bucolic landscapes, both sexy. Podcasts, articles, intelligent content, that’s here too! There are no rules.

We’re all a bunch of early adopters from around the world who (for the most part) are having a grand ol’ weird internet time.

Oh, and there’s also magic internet money.

So who am I? Idk I’m still figuring it out.

🤙🫂 PURA VIDA NOSTRICHES

#plebchain #intros #grownostr

Pedro Vicente 2y ago

Grand ol’ weird internet time for sure. 🙃 “Free speech is essential to a functioning democracy” https://fee.org/articles/did-elon-musk-just-save-free-speech/

Replying to

Pedro Vicente

C is the way to code here. That JSON library, JSMN, is pretty slick, very low level, I used it before, but I use C++ now and ‘JSON for modern C++’ . Still working on my CMake port , will post here when done https://github.com/damus-io/nostrdb/commit/32b0e572e418b81af515224cc7eb3b1e8598d906

Pedro Vicente 2y ago

*meant to say C is the way to go, but the “way to code “ works too… probably some Damus auto correct 🙃

Replying to

jb55

I already have a fast C content parser 😅. I’m using C code in Damus. Since it’s depending on lmdb, it made more sense because lmdb is a C lib as well.

This will also work in rust and notedeck, I’m planning on making a rust interface.

Pedro Vicente 2y ago

C is the way to code here. That JSON library, JSMN, is pretty slick, very low level, I used it before, but I use C++ now and ‘JSON for modern C++’ . Still working on my CMake port , will post here when done https://github.com/damus-io/nostrdb/commit/32b0e572e418b81af515224cc7eb3b1e8598d906

Replying to

jb55

my bad it must have slipped my inbox

Pedro Vicente 2y ago

Thanks. I’m trying to port nostrdb for windows using Cmake , seems very easy because the code is so simple. Fixed 2 build errors and test works only fails because I have to allocate memory in ndb_tag (declared as c pointer instead of that array zero size declaration)

Replying to

jb55

working on an embedded database custom-built for nostr. think an embeddable strfry. It will probably be the fastest special-purpose database on the planet once it’s done.

I’ve built a custom in-memory note representation with O(1) and zero-copy access so that you can memory-map the data from inside lmdb directly into your data types without needing to serialize anything in and out.

if that didn’t make sense, the TLDR: shit is about to get real fast.

https://github.com/damus-io/nostrdb

Pedro Vicente 2y ago

“Fastest database on the planet” sound ambitious. Unrelated: I added CMake build and a Windows port for nostril couple months ago, submitted a pull request , but got no response (also adds the secp256k1 source, but that can be taken out) https://github.com/jb55/nostril/pull/30

Replying to

Pedro Vicente

Great question. The beauty of Nostr is that is so simple, it is basically only NIP-01, so any change must keep that in mind. Going by parts:

1) kind 2: recommend_server. This seems to be an optional feature, and optional features are bad to begin with in any spec (imo).

This one seems not to have a good chance to be "correctly" implemented.

If a relay is behaving good or badly, we can just advertize that in the community?

No need to be written in spec. And if no one uses it, then yes, get rid of it (that's the first thing I do when a function

is depecretated, remove it from the code base).

2) NIP-12. when adding new features to a spec, we should ask. What are the pros and cons? Does it make the spec more complex?

With complexity, we loose adopters. But by adding useful but not essentially required features to a functional spec, we gain

adopters. So, it's a trade-off. In this case, NIP-12 seems to have *very* good use cases, like the

#g ("geohash") tag to associate a post with a physical location (See Leaflet of Google Maps). Maye an alternative in the middle between

putting this NIP and others into the main NIP and leaving it alone, could be to do a "Core NIPS" or "Top 5" kind of thing. Don't know.

3) NIP-20. This one seems super important too, an acknowledgement reponse (just noticed that is not required in Nostr).

I think most Internet protocols, like HTTP or FTP, have a response built in, which seems critical in life saving missions

or money transactions (but not posting cat pictues to a relay). So, same answer as 2) , either in main NIP or "top 3".

** Inserting an idea for NIP-01 here **. Add a boolean key/pair "response": true/false that says , I do require a response or not. This

fits nicely into JSON, boolean types (it seems Nostr has none) . Is this a good idea? If yes, I'll write a proposed change to NIP-01.

4) NIP-16 replaceable events. Maybe not a Top one, don't know.

Pedro Vicente 2y ago

Also 💜 that I can write all the stuff above without having to pay $8/month 🙃

Replying to

fiatjaf

I want to clean up NIP-01 a little more, remove the things no one uses, like kind2, and merge in NIPs 12, 16 and 20. Is that a bad idea?