Thanks JB! It’s the less vocal crowd who care and value your efforts most.

Just think, you’ve single handedly off-boarded more twitter users than anyone else I know.. maybe even in the entire universe 😅

https://github.com/0xtlt/nostr_rust/blob/main/src/events.rs#L127

https://github.com/scsibug/nostr-rs-relay/blob/master/src/event.rs#L359

It can be hard too when we’re still so early. Writing FAQs or Knowledge Base articles to refer people can help.. but they take time and often go outdated as things are improved or addressed quickly.

Support is a key reason why I haven’t opened up more public Nostr services. I can’t do what I enjoy if 70% of my time becomes support work.

Venture capital is just modern day gold prospecting.

You can look at some Nostr library code and open source apps to see how’s it done today.

Certainly could be more strict. But it leverages existing JSON programming language libraries, which likely have already mostly standardise.

The signature is only signing the event id, not the serialised event. But again, I’m yet to see any issues in the wild.

I had concerns too, but I haven’t yet seen one complaint about failing/invalid event ids.

Here is the extract from the NIP-01, which strictly defines how the hash digest must be formed prior to hashing the event id.

As a reference too, I haven’t tested it yet for Nostr, but hear great things.

“SurrealDB is an end-to-end cloud native database for web, mobile, serverless, Jamstack, backend, and traditional applications. SurrealDB reduces the development time of modern applications by simplifying your database and API stack, removing the need for most server-side components, and allowing you to build secure, performant apps quicker and cheaper. SurrealDB acts as both a database and a modern, real-time, collaborative API backend layer. SurrealDB can run as a single server or in a highly-available, highly-scalable distributed mode, with support for SQL querying from client devices, GraphQL, ACID transactions, WebSocket connections, structured and unstructured data, graph querying, full-text indexing, geospatial querying, and row-by-row permissions-based access.”

https://github.com/surrealdb/surrealdb

I agree.

The challenge I see however is being honest, centralisation is easier. Decentralisation is harder.

Many things solved for big tech doesn’t work well for decentralised (discovery, spam, data persistence, availability, etc).

We basically need to reinvent ways to do these things - and often on smaller lower powered devices like mobiles.

Until we can make things simple, sometimes we just need to make them work first.

I don’t have the answers today. I experimented a little in the past with hypercore. I didn’t enjoy it.

I’m hoping others with p2p interest or experience can try experimenting too. I’ll continue, but at a slower pace.

Not everything has to be p2p. And we have a p2p payment mechanism now, so p2p could also mean value for value. Lots of possibilities.. we just need to experiment and try crazy ideas.

It’s a critical take on Nostr, but if we distill the core innovation - it’s the simple cryptographic Event JSON payload - and the protocol’s openness.

Websocket relays are ok, but Nostr can work over hybrid p2p or REST. The query engine is ok, but it’s basic and has design faults and limitations.

So why write this post?

I think we can expand on todays relays and evolve the event transport layer, likely to many simultaneous methods including a p2p layer, and greater privacy.

I think we can reimagine the event query engine, allowing for more performant and expressive queries. Perhaps GraphQL, maybe feature from new streaming databases like SurrealDB.

I think if we open the box a little more, we can start to explore new and powerful innovations that can expand upon the NIP-01 primitives.

If we start to experiment and challenge ourselves to discover new ways to make Nostr unstoppable, I think we will find amazing new capabilities are possible and bring forth a wave of communications innovation.

Yep. Covid “Fact checkers” were just spindling the government’s truthspeak.

The actual truth was we didn’t know or have enough data at the time. And still don’t.

And if you looked at most media headlines today, almost all would fail sane fact checking - embellishing, biased, opinion as fact, over descriptive to stur contention, etc.

It’s a skill we need to teach and learn ourselves. A self bullshit instinct detector.

Working as expected.

If only we could give them enough rope…

I don’t want to rip on Bluesky too much (I actually encourage experimenting), but isn’t it a red flag that you need an invite code 😳

“The web. Email. RSS feeds. XMPP chats. What all these technologies had in common is they allowed people to freely interact and create content, without a single intermediary”.. but bring your invite code, or no bueno

Ask not what your government can do for you, but ask what you can do for your government! - Irony

“Please mention me in the next hell thread? Will zap!”

Depends. Most the the job of a relay today isn’t querying your own events, it’s events of people you follow and conversations that stem from that. I’d suggest trying a paid relay before running your own.

Nostr.wine is decent.

And the key issue isn’t just one guys 250,000 self DMs, it’s 1,000 or 10,000 of people who do the same. And when we grow again by 10x or 100x. It hurts smaller relays the most.

A personal server can make sense as a local backup. It doesn’t need to be public.

It’s funny how painful it is for people (I’m stuck there too 👋) and it’s not even push notifications, ha.

Maybe limit a mass reply all too? A warning may not be enough.

Sure, but at some point blastr relays will become rate limited themselves or need a PoW event to prove they are not spam.

The secondary issue is relay event aggregation. You can’t just block IPs, as you don’t know the poster. And we need aggregation or we will never get a broader set of stats like reaction counts, replies, etc. you will be stuck with a smaller pool.