90% of my days
Long-term Support for Nostr Developers from OpenSats
https://opensats.org/blog/nostr-lts-long-term-support-for-nostr-developers
🔂 crossposted from https://ccns.sebastix.dev
Excited
relayed.deno.dev now supports EOSE
I just googled turd and I regretted. My eyes are polluted.
I don’t care too much about the bitcoin bull. This year I want Nostr bull. I want Bullstr. I want 1 million regular nostr daily users. The bitcoin halves, we doubles.
So kickstarter is a crypto company now?
Is this a lyric. Beautifully put
Dude, you have mental issues. Have you talked to real people recently? Chill the fuck out.
Yes, on dedicated relay(s) will work. This is what I plan to do. I gave up on random relays.
You asked the key question.
The future Blowater will be more like Discord and treat each relay as its separate place.
First of all, it need roles.
Relay Owner, Relay Admin, Normal users etc
If we also assumes that relays don't need to update its code to support special client features. Then, I would like to have relay owner sending an event that describes all kinds of resources & roles relevant to this client, such as
{
roles: {
admin: {
write: "all"
read: "all"
},
normal_user: {
write: ["resource_1"]
read: ["resource_1", "resource_2"]
},
}
then, in the tag of kind-1s and other events, blowater will attach the resource type
{
tags: [
["resource_type", "resource_2"]
]
}
Something like this. It's like a type system for resource access control.
If relays do not support it, Blowater can just do it on client side.
Of course, it's always better if some relay implementation support it. This is another reason that I am writing a tiny JS relay implementation. I can do this kind of end-2-end expriment quickly.
But Blowater does not even have these features yet. So it's not an immediate problem to solve yet.
Authentication matters, meta data leaking problems matter.
Technically, NIP-42 solves authorization, not authentication.
I can't speak for other developers. Blowater left out NIP-42 because it does not fit into how Blowater wants authorization to work. Blowater has its own design to mitigate metadata leaks problem (which does not fully address it yet). This design does not have to interop with other clients because other clients are not likely to address the same set of features anyway.
There is no universal authorization scheme that works for all software. I have implemented multiple SaaS product in my career and have worked with many 0Auth providers. If this problem is simple, it won't be a multi-billion market.
The previous note is just my frastration of that "get event by id" is a stream. It makes no sense because events are immutable.
A relay either has or does not have an given event id.
It makes client's network code a bit longer. Not a big deal but still could be better.
I don't call it ugly but yes it's very minimal at this point.
The whole point of Nostr is that different platforms can have its own best client implementations for Nostr features.
Therefore, one client should just focus on one platform.
https://blowater.app is always a desktop client which happens to be able to render on mobile web, partially.
NIP-42 is intentionally not in the scope of this client because it was never the design goal of the product.
Not all NIPs are suitable for all client. The design goal is important.
nostr:npub10npj3gydmv40m70ehemmal6vsdyfl7tewgvz043g54p0x23y0s8qzztl5h From a system engineering pespective, if we can all agree on the data structure of Nostr events, why do we have to have the same API? For example, a GraphQL API over a relay can be much more expressive than current filters API. Does it really make things more complex? Not necessarily. Mainstream web systems are request/response oriented and streaming API is added later. Nostr is the other way around. It does not have request/response model for its events.
What is this?
Going fully encrypted, including meta data about the chat, is very challenging in client engineering. Because it gives up all the filtering capabilities of the relay. I wasted too much time last year trying to achieve this goal, sacrificing product development speed. I believe it’s possible, just too early for me.
Not specific to NIP-87, but
1. Fully decentralized encrypted chat rooms is impossible because relays npubs are not guaranteed to have common relays. Not guarantee of relay synchronization among themselves is both a shortcoming and advantage of Nostr design.
2. It’s better to join define a single relay for a specific room. Then, we can either have fully encrypted chat or relay aided authorization. Maybe both.
This is surreal! I wrote a relay in an hour and now it's deployed. I can't believe that it works wss://relayed.deno.dev
Don't get mad at me because I just implemented yet another relay.
This is not off-tracking because as a client developer, I need to understand Nostr full-stack in order to achieve excellency.
This relay is not here to compete with strfry in performance. It's a pure-in-memory relay for other use cases.
For example, when a developer just want to start a dirty relay in localhost for testing purpose or other short-lived relays.
It's also my place to experiment with unique nostr API designs that's different from the NIP standards.
It will be open sourced once it can serve all Blowater client's needs. Meaning at least kind-0, kind-4, kind-1.