Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Nostr.how – A Complete Guide to Nostr

nostr.how

Post reply on HN
Print view View original

121–130 of 140 posts

Re: Nostr.how – A Complete Guide to Nostr

#121

Post by pointlessone »

leesalminen wrote: post #73
kemitchell wrote: post #65

Earlier quoted context omitted.

> Message signatures are signatures of stringified JSON. Given that JSON is not particularly well defined to guarantee representation stability are implementation differences handled? Systems I've seen (and written) that do this use deterministic serialization algorithms that sort keys and do other things standard, general-purpose implementations don't. The implementations in core libraries, browsers, and the like te…

Taking a look at NIP-01, the serialized data that gets hashed and signed is a flat array, not an object. So no sorting of keys here. I don’t think any json serializer would change the order of items in an array, right? https://github.com/nostr-protocol/nips/blob/master/01.md

That's true but there's still plenty of room for incompatibility. JSON doesn't put any requirements on floats precision, for instance. Another example is that any character may be escaped (that's in the RFC, literally, verbatim) so while it's recommended to use UTF-8 for serialization a random lib can decide that ASCII is the way and escape all your emojis. To be fair, NIP-01 specifies that it has to be UTF-8 but no mention of float precision can be found. I'm almost certain these two are not the only ways a JSON can be divergent while still being valid.

And I have to point out that we're doomed to repeat our mistakes. XML is also very flexible. And people wanted to sign XML documents and they found this to be a problem. So they came up with Canonical XML form — a way to remove some of that flexibility to make sure it's possible to reliably derive a stable variant that can be signed and verified. Unfortunately, we haven't came up with Canonical JSON yet. But maybe we will soon.

Re: Nostr.how – A Complete Guide to Nostr

#122

Post by drowsspa »

leesalminen wrote: post #120
drowsspa wrote: post #96

Honestly, I don't get the fuss about these "libertarian-inspired social network protocols". It's not like the technical side of social media is the tough one: it's always been the political and sociological one. In the end, most people aren't hardcore libertarians and do want content moderation, centralized discovery, spam blocking... I would really find it interesting if it came about a protocol that actually cared…

There's nothing about nostr that prevents any relay and/or client from offering these things (content moderation, centralized discovery, spam filters). They could even share their findings with other relays/clients and build one big cohesive censorship system. If this happened, users would be free to opt-out of that and switch out their client and/or relay with other options that fit their needs without friction. The…

"Could", "just", "simple". Sounds like "draw the rest of the owl".

Re: Nostr.how – A Complete Guide to Nostr

#123

Post by toomim »

pointlessone wrote: post #121
leesalminen wrote: post #73

Earlier quoted context omitted.

Taking a look at NIP-01, the serialized data that gets hashed and signed is a flat array, not an object. So no sorting of keys here. I don’t think any json serializer would change the order of items in an array, right? https://github.com/nostr-protocol/nips/blob/master/01.md

That's true but there's still plenty of room for incompatibility. JSON doesn't put any requirements on floats precision, for instance. Another example is that any character may be escaped (that's in the RFC, literally, verbatim) so while it's recommended to use UTF-8 for serialization a random lib can decide that ASCII is the way and escape all your emojis. To be fair, NIP-01 specifies that it has to be UTF-8 but no…

Canonical JSON has a IETF RFC: https://datatracker.ietf.org/doc/rfc8785/

Re: Nostr.how – A Complete Guide to Nostr

#125

Post by mattdesl »

leesalminen wrote: post #118
mattdesl wrote: post #112

Earlier quoted context omitted.

Two uses cases that would both be beneficial to nostr: Decentralized namespace registries - see Farcaster. Autonomous and decentralized mechanism that rewards & incentivizes users to run nodes/servers - see Ethereum staking, Filecoin.

No need for any of this elaborate noise. You can just charge money for services rendered like hosting your media or notes.

That describes most centralized services on the web today. Nostr and other decentralized protocols aren’t aiming to recreate the Twitter and Amazon model.

Re: Nostr.how – A Complete Guide to Nostr

#126

Post by anonkogudhyfhhf »

legutierr wrote: post #114
anonkogudhyfhhf wrote: post #101

Earlier quoted context omitted.

Nostr already has bitcoin payments for incentives. Please example one concrete example where a blockchain is needed for nostr protocol itself

There are two places where a blockchain would be very useful in this context: guaranteeing completeness (allowing you to confirm whether or not you have downloaded all the posts ever created by a user), and preventing timestamp forgery.

You wouldn't want text messages on a none scalable blockchain.

Timestamping is already possible using the bitcoin blockchain. No token scam or new blockchain needed

Re: Nostr.how – A Complete Guide to Nostr

#127

Post by Zamicol »

andirk wrote: post #92
Zamicol wrote: post #37

Earlier quoted context omitted.

DNS is centrally controlled by ICANN. There are alternatives like ENS. I don't mind Nostr just simply having its own system.

At the top, sure, but our machines have their own DNS so we could get around the ICANN DNS servers if we told our machines to do so. Is that what ENS is?

One of the first applications of blockchains was DNS. (Namecoin) ENS is a modern form. (https://ens.domains)

I would say there's still some degree of centrality for ENS, but it is more decentralized than DNS.

Re: Nostr.how – A Complete Guide to Nostr

#128

Post by leesalminen »

mattdesl wrote: post #125
leesalminen wrote: post #118

Earlier quoted context omitted.

No need for any of this elaborate noise. You can just charge money for services rendered like hosting your media or notes.

That describes most centralized services on the web today. Nostr and other decentralized protocols aren’t aiming to recreate the Twitter and Amazon model.

There already exist nostr user verification service providers that charge a fee for a purple checkmark, similarly to Twitter Blue.

Re: Nostr.how – A Complete Guide to Nostr

#129

Post by leesalminen »

drowsspa wrote: post #122
leesalminen wrote: post #120

Earlier quoted context omitted.

There's nothing about nostr that prevents any relay and/or client from offering these things (content moderation, centralized discovery, spam filters). They could even share their findings with other relays/clients and build one big cohesive censorship system. If this happened, users would be free to opt-out of that and switch out their client and/or relay with other options that fit their needs without friction. The…

"Could", "just", "simple". Sounds like "draw the rest of the owl".

Nostr is being built right now. We’d love for you to join us, it’s just a PR away!

To be clear, Damus already offers some level of content moderation. Other clients are accepting PRs to implement as well. Nostr itself offers some level of centralized discovery with NIP-05. Relays are starting to look at spam filtering (via pay-to-post models mainly).

Re: Nostr.how – A Complete Guide to Nostr

#130

Post by leesalminen »

topranks wrote: post #111
gray_charger wrote: post #7

Earlier quoted context omitted.

I think centralized moderation is the problem with social media servers. Users should be the ones to control their own moderation. See a post you don't like? Hide the post. Don't like any posts from a particular user? Block the user. It's not difficult to do and if users are really only following friends and famous accounts (celebrities, bots, news, etc.) they won't experience much spam anyway. I think the real issue…

I don’t want to have to look at abuse material just to tell my machine to block a user. And play whack-a-mole as they reappear etc. Moderation is vital for public social platforms.

These notes can already be flagged and reported. This action generates another note of a specific type. A nostr client could use this data and hide notes from users before they ever see them.
Post reply on HN