jb55

most nostr apps you can click a single button to create an account, since it just generates a keypair. no email verification, nothing. what is simpler than that?

you don't even need to know how to host something on a server, the relays do that for you.

> The event protocol that drives the system doesn't authenticate public keys, so asymmetric signatures are performative: attackers that can intercept messages (Nostr servers, the presumed adversary of an E2EE messaging system) can just swap out keys and re-sign.

This is completely nonsense, most clients do in fact check signatures. All relays do as well.

> Two major clients, the mobile phone Damus app and the web Iris app, don't even verify signatures to begin with.

Author of Damus here. this is an analysis of an old version. This has since been fixed. In the early days we connected to a fixed relay list of trusted relays. These relays verified signatures. This was just a pragmatic tradeoff thing until we had an optimized work queue for verifying notes (this lead to nostrdb, a custom embedded nostr database built on lmdb. it's a sqlite but for nostr https://github.com/damus-io/nostrdb)

> DMs in this system are unauthenticated CBC, so attackers can simply bitflip messages and events to say what they want.

not really true since the whole note is covered by a secp256k1 signature.

> The apps do automatic link-preview, so they've managed to reconstitute the EFAIL attack: attackers can locate links within messages (they'll be revealed by SNI and DNS anyways) and then bitflip them to point to attacker-controlled servers, exposing both the URLs (which will often contain tokens) and, with a bit of extra work, the message itself (by tacking `?foo=` onto a URL).

you can turn off these, you can turn off images as well. people should run a VPN of course if they are worried about these things.

I have had the experience of explaining to coworkers how bitwise operators even work more than once. I think sometimes people overestimate the average programmers knowledge when it comes to bit operations. modern programming is so detached from having to use that for day to day work.

I am aware of the bithacks page, but I just found encoding the bit coordinate in the ID itself so clever.

i updated the wording, hope its more clear

prs welcome

updated for the hacker news crowd

https://github.com/jb55/oot_bitset#:~:text=Hacker%20news%20f...

I will remove the novel wording just for the hacker news geniuses. I have been programming for 26 years and have never encountered this pattern, nor could I find it in any libraries, which is why I decided to wrap it up in a library.

If a simple bitset like this exists in a library somewhere I would love to see where! Most implementations I've seen over-complicate it for simple use cases like this.

Images are not stored on relays, so they would not be targeted. The image hosts have the liability, not nostr.

There is no "zaps balance". Zaps are just receipts of lightning payments.

The basic idea is that a lightning node will detect when the invoice with a nostr note inside is paid, and then send the receipt to nostr as a nostr note, with the original bolt11 invoice inside with the signature from the user who sent the zap.

It's all described by NIP-57, a spec I put together to support this:

https://github.com/nostr-protocol/nips/blob/master/57.md

I was working on c-lightning at the time and I thought it would be really cool to replace the "like" button with an instant bitcoin micro-payment. I think it worked out quite well! There are many sites utilizing zaps in all aspects of the protocol, such as a decentralized market for AI job requests (data vending machines), zapgoals and zap fundraisers. All built on this note type. protocol synergy!

Zaps just put a signed nostr note inside a lightning invoice so that clients can show that a specific user send some amount of money to some note or profile. clients request lightning invoices via lnurl (an http lightning specification). You could do the same thing for any other fiat or crypto system if you want to, but nostr was mainly build by bitcoiners which is why there is lots of bitcoin tech integrated, but its completely optional.

I guessing this is because you are used to an algorithm that is constantly showing you the most liked content. average day to day discussions between humans can be pretty shallow, nostr feels more like shooting the shit with your friends instead pumping rage bait and dopamine into you brain 24/7

This is also why I suspect people are generally nicer and happier on nostr, there is much less fighting because there is no algorithm that boosts angry and controversial threads.

not to say algorithms can't happen on nostr, there just aren't many in clients yet.

Correct user counts need to have a web-of-trust applied if you want an accurate count of "real followers", but I suspect that's the same on X as well.

As one of the largest accounts on nostr I can say there aren't many "crypto" fans on the network, those are all on farcaster. Lots of bitcoiners and freedom lovers though! Maybe try following #grownostr, there is lots of non-"crypto" content, mostly gardening, homesteading, etc.

You have to curate your feed to see the things you want by following specific people. There are no algorithms that automatically tailor the feed to your interests. If you go into the "global" or "universe" feed you will see lots of crap, but that is just noise that can be filtered out by setting your global feed to only show paid relays.

Hey, author of https://damus.io here (ios twitter-like nostr client)

> First, I want a replication strategy. Nostr messages get lost in time, and many of the clients end up just blasting an entire message history at your client. Because there's no clue in the protocol how messages are related other than a timestamp this also means you can fake timestamps and write fake messages in the future or back in time

You can do this with email or git too and it doesn't make it any less useful. I actually like the backdating feature as it allows you to copy your account to a new key.

As for replication, at damus I am working on https://github.com/damus-io/nostrdb which is intended to be a "sqlite for nostr". I plan on implementing set-reconciliation based syncing with strfry relays (using a technique called negentropy), so that replication is very efficient.

> Second, I don't like that many Nostr clients are using the same signing key for messages as they do for lightning transactions.

This is simply not true.

> Third, someone needs to delete some of these NIPS. The arms race to make Nostr as complex and difficult as possible to implement is not going to do much for the ecosystem in the long run. In the beginning Nostr was simple to implement from scratch, they should get back to that!

All nips are optional except for nip01, you can ignore them all for the most part.

> Fourth, it needs a dedicated blob store protocol. Yah, I know IPFS isn't great but someone should come up with something that is simple and works.

It does not, in the same way email or git or any text-based protocol doesn't need a dedicated blob store. These are separate concerns and they should be a separate protocol. nostr clients can of course integrate and link to any blob store it wants via new NIPs that describe this. I believe there are a few already in the nips repo.

Cheers!

The damus relay rate limits even if you have multiple keys

I don’t think it’s important to dive into tech details on the damus homepage. Gmail doesn’t attempt to explain the email RFCs when creating an account.

Damus does not manage your lightning wallet. All it does is open lightning invoice links in an external wallet when you want to zap someone.

All of this is optional and opt-in.

Its optional, you don’t need to attach a lightning address to your profile and you will receive no bitcoin for your posts.

Author of damus[1] here. We’ve seen a crazy growth in nostr in the past couple of months. Damus itself sees about 1000 to 10,000 download per week, and we’re up to about 500k to 1mil+ users (hard to get exact numbers on a decentralized network). Exciting times for social networking protocols!

[1] https://damus.io

It's only recommended that you store json and text on relays. It's a text protocol, not a protocol for storing large binary data. Note sizes are restricted as well on most relays.

Hey, author here. This is built on the nostr[1] protocol which has many advantages over activitypub. I highly recommend reading the readme on the github for motivation on why we would need yet another decentralized social media protocol.

Happy to answer any questions :)

[1]: https://github.com/nostr-protocol/nostr

For anyone interested in how I gathered these: I noticed a versioning pattern from the snippets he was sharing online. I started poking around and tried to put together a git history of changes by guessing version filenames on oculus' s3 bucket.

So if you do `git log --reverse -p c9bd14f361cc4e537425f6d634367415059ad5e3..HEAD` you can see a snapshot of some of his vrscript development

> Yes, of course one could use some fancy cryptocurrency

I paid a bug bounty to someone in Germany from Canada with Bitcoin. I guess I'm a terrorist now.

You can do this with Trezor. It allows you to enter a 25th word to your seed when you unlock it (it looks like you're just entering your password, but you could enter any password), generating a whole new set of private keys. Although this makes less sense in the context of a PGP key...

I use a Trezor to store my PGP key. I never have access to the private key, it's generated by a seed which I backup in a cryptosteel protected by a password in my brain (to prevent physical theft). The device only provides an interface to sign and decrypt. This keeps the key safe even if your computer is compromised. See: https://github.com/romanz/trezor-agent

> I've gone through multiple image editors on Linux, and none of them have the simplicity of Paint

Have you tried mypaint?

With Bose Quiet Comfort + electronic music, I find it blocks out talking pretty well

> I know I saw a few devices (like gloves) at SIGGRAPH that attempted to reverse engineer tracking with the base stations

I'm attempting to do the same thing at the moment: https://github.com/jb55/libvive. I got basic stuff like buttons and gyros working. Right now I'm wrapping my head around some of the trigonometry that makes the lighthouse tracking work. Hopefully I'll have an open source reference implementation soon.

Nix has a way of doing this as well, just needs a better UX (like most of nix).

Indeed, this quickly becomes obvious after writing Haskell for awhile. Lawless typeclasses just seem clunky and get less reuse compared to their lawyer'd up brethren.

You also can get a very slight taste of this in C#, Java, etc as well where larger interfaces seem clunky and get less reuse than smaller interfaces. In C#, if an interface has some nice properties, typically the extension methods on these interfaces with allow for a combinational explosion of generic utility functions. So this might be one way to judge the "algebraicness" of interfaces. You see this a lot of the LINQ collections libraries, which seem to have put some thought into laws.

Unfortunately in these languages you can only go so far due to the lack of higher kinded polymorphism (T<A> types vs just Type<A> types).

I have a standalone implementation here as well: https://github.com/jb55/Data.Maybe.cs