nostr:npub14kcnaaguwqww5cac9m2p755g8z0ugpg7zzcnczll5al86cwfj67sjk2chk we need markdown in Blowater
I still think AI is a nice idea to Nostr. Using GPT4 to help with Nostr development. Itβs cheaper than a cup of coffee per day and I can work much less.
Blowater will release a new reply feature. 
A problem has been bugging my mind since the ever beginning.
What should be the role of relays?
If we treat it as a node of a distributed system, such as a Cassandra node, then it should not differentiate and clients just treat it as an opaque network & storage layer. All the replaceable events & consistency discussions come from this angle.
If we treat it as a discord server or a Slack workspace, then each relay differentiates in content and possibly in functionality.
Right now, most developers seem to want relays to be both. But these 2 have very different design trade offs . Wanting to be both might just end up being good at none.
Or, maybe some developers havenβt thought of it consciously.
Fruit for thought: should relays be aware of each other? Should the awareness be mandatory like a distributed system or just a nice to have?
For example, a DM client has very different needs for relays from a social client.
NIP19 is overrated
After 2 weeks of intensive bug fixing, blowater.app is much better now. Next week we will redesign the signin & onboarding flow. The mobile version of Blowater is also not painful, finally
Assuming meta data leak is solved, does relay choice matter for DMs? Maybe all DM clients should implement gossip model or other routing strategy to solve delivery issue.
There is one surprising observation I have.
Blowater has been reliable in Feb and March. Starting April, I started to address many of the pain points of it and half-a-year later, it has been becoming more and more unuseable.
For the past 2 weeks, I have been removing many of the "upgrades" of Blowater and now it's back to Feb level reliability.
Why did more work cause the software to be worse?
There is a meta lesson to be learned. I don't know yet.
nostr:nprofile1qqs04xzt6ldm9qhs0ctw0t58kf4z57umjzmjg6jywu0seadwtqqc75spz9mhxue69uhkummnw3ezuamfdejj7qgcwaehxw309aex2mrp0yhxxatjwfjkuapwveukjtcpzamhxue69uhkummnw3ezuun9d3shjetj9eek2tcwrcz23 Relay reconnecting has been the most mind bugging part of implementing a client.
WebSocket() constructor is blocking and sync and no "force close" on the client side for web socket.
Relay may disconnect at any point of time. Reliable re-sub of queries is crutial.
What's your experience of implementing NDK's networking layer so far?
Am I too crazy about testing coverage? I feel I might be over engineering the relay pool and under engineering the application.
setting up their own relays and config this relay to be very unreliable such as randomly rejecting events or disconnecting after very short amount of time.
Testing against unreliable relays should be mandatory for all client developers.
A well designed application does not need an onboarding / tutorial step. The tutorial is emerged into all the UIs.
I ate many orange things in Wakayama
We have 10+ PR today for all the projects under Blowater umbrella. Amazingly productive day.
Relay records of events are finally implemented in https://blowater.app
NDK has 3X more features. nostr.ts is more comparable to nostr-tools.
More than 10 PRs to just address relay connection & auto reconnection issues in the past 2 weeks. Now https://github.com/BlowaterNostr/nostr.ts has probably the most reliable relay connection layer in all JavaScript clients.
Now I just need to adapt Blowater to the newest version of nostr.ts
Auto relay reconnection has been moved from Blowater application to nostr.ts library. All nostr.ts users now get better network stability.
You need to do a graph building algorithm for such a case.