When you work on stuff that matters it's much easier to make decisions. Trade-offs magically become less complicated.
STERRY
npub17dmm...tduz
Explorer and early adopter, painter, musician, coder, movie buff, bitcoiner, family man.
I love Nostr and not just for the kind 1. There's so many use cases that are in there with a massive power to grow. I want to unlock the solving of ever more problems.
If you've ever had a NIP left hanging or flat out denied get in touch!
Might be cool creating a relay plugin that translates into kinds to versioned strings maybe even pulling info from tags to do so.
What would your app or relay do if kind came in as a string?
Thinking now that as much of Nostr's underlying tech should be used in any upgrade process. You want to make it easy to upgrade the pieces that solve problems for the user/dev/company whatever.
The cool thing about key delegation is you can easily make a single key a subkey of a new master simply by signing in both directions. Then the first time clients see a new key they can look for the two delegation proofs and associate the right master identity.
Made progress today getting strfry running and testing some ideas. Main takeaway to retain nostr compatibility is not to mess with the top-level structure of events. Tags provide a fertile and optionally indexed dataspace in which many things can be added outside of new signature mechanisms.
There's a peace to setup docs that just work. As I run the scripts, it's all understandable and good. Compiling C++ is beautiful.
Feels good knowing that content on Nostr isn't censored re Vylan and Graphene.
A bit concerning that the two biggest relay packages nostream and strfty haven't seen git activity for months. Strfry has plugins which helps but hard to believe they're that stable! Maybe dev is happening in another place...
In any case, going to setup strfry for development because I believe the best path forward is a kind of softfork.
Let's get it! Feeling hopeful today that more progress is possible in a Nostr-native sense.
I'm working to set up a dev relay to test in practice how spec version and error reporting data can be added to Nostr events. Are new top level fields allowed or do we need to "softfork" in via tags?
Tempting to take shortcuts but going to focus on doing the work necessary to operate at the state of the art. We got this!
When does a hug start to get weird?
You know the feeling. After a second you have to start adding pats and words like "it's good to see you" or "it gets better" or go full goodwill hunting with an "it's not your fault."
I feel like the embrace between Nostr and chaos started to get weird a long time ago. A little chaos is good but there are other philosophies to greet such as order, sanity, and efficiency.
I think it's great that more serious discussions are being had about Nostr. I believe competition is good at all layers. That's why I'm creating a set of specs that can help try new ways in an orderly manner. Attempted to get a development relay up today and made good progress. Would probably help if I went outside the python comfort zone. Back at it tomorrow!
You can just add data to Nostr events.
It takes courage to share the full extent of your wisdom, but compassion makes it easier.
#blossom is this how this works? 

Concerns this morning about whether it's possible to extend a nostr message. `type` doesn't seem practical as a new field name so trying out `taxon`.
Working on Corgi not just to try out new ways but to give others a place where they can document their new ways.
Hopeful that I get some actual data flowing today and the draft specs become more accurate.