💯 The dev is on github. I haven't found them here yet. Still putting the word out. Will let you know when I know something.

I guess the spec is not very clear as it mentions "errors" only on NOTICE, maybe that's why most relay implementations do it that way

Oh ok got it. So errors then should be sent with CLOSED, rather than NOTICE + EOSE.

That is exactly what "CLOSED" is for.

This is strfry. Maybe you're using an "#e" or "#p" with invalid hex.

It's very early. It's only the first release of a live test version (0.2.0) so there be dragons, but it's surprisingly stable. Though don't sent more than you're okay with losing and periodically transfer out to another wallet.

garnet is forked from an Amethyst version just before Vitor went with the gossip model and there are little bugs that Amethyst already fixed. The biggest bug I've found over the past couple days of testing is trying to edit a draft deletes the draft.

Also, it does not install if amethyst is already installed due to conflicting signature but same app details. However, some have used apk editor to install both alongside each other.

Personally, I nuked Amethyst because I accept the risk of this alpha/beta release and know I going to daily drive it so I can help the dev with fb.

If you're good with the above, give it a spin. It's awesome!

because notice doesn't always mean that there's a subscription issue

Awesome! Fantasizing with the portability capacity of this, would be awesome that some day I can just intall a zap.store in a fresh machine and have all my apps there👀

Need more of this kind of video content on Nostr. Repoast

nostr:note1yjhte0zvudcwn6p94cuvg0gkjd6vx9ly85n8z9twv8lktcw3e5cqm9vw0m

Until Google EOLs Dart.

If you have an npub that'd be great so we can show the author in the UI and eventually they'll be able to get zaps

secured by Bitcoin proof of reserves?

Summer days and… [fill in with whatever makes you happy during summer]

OK, I'm not opposed to having other way to query things -- but again if you're doing this for specialized use cases maybe it's better to have specialized queries that are specific to each use case.

Is there something worse than js/ts?

Well, link it here when you are ready to discuss the NIP

When I said "bad behavior" what I had in mind were some people who were literally trying to sell Nostr relays as free databases for custom web apps some time ago, and then some recent attempts at using NIP-32 to store events with tags like L=name, l="something" L="author" l="someone" L="date" l="2024-07-20" and then do queries using that -- the way I've seen people do makes no sense, but you could have just different tags and values without the L/l overhead and then you would query all albums released in 1973 by bands with names starting in F that have less than 6 songs with {"#s": ["f"], "#y": ["1973"], "#n": [1,2,3,4,5]}.

You get the idea: people shouldn't be doing this! And if we make it easier they will do it more, and then it will be more hassle for relays to change themselves so they can block it.

Also powerful query language means it's easy for bad actors -- or just bad-coded well-intentioned clients -- to DoS relays.

How can you learn without fiddling around?

Well I couldn't think of something we could remove from the query language. I just think tag querying is too open-ended, like in theory you could query for a million tags (in practice it won't work).

I like the final point, but I think it makes it bad for implementations. I like the idea that anyone can make a relay implementation very easily, even if they create their own indexes manually. If we start depending on either SQL blackbox magic that would be bad.

Having a query language too flexible would also encourage bad behaviors in application developers, treating relays as full-fledged ultra-flexible databases, which they shouldn't be in my opinion.

I don't know.

Communities I'm planning to start/join when NIP-29 starts going places:

🍊 Metabolism Go Up

Discussing anything on the workings and the unlocking of the human metabolism

⚡ Zapostles

Deep dives into the Bible from a zappers perspective

:Nostr: Nostr Design

Obviously...

🌊 Cataclysm Crew

Gang of citadel builders that are into space weather, the how's and why's of magnetic pole shifts and earth's disaster history

🍆 NIPs Out

High Signal on the latest and greatest of Nostr Implementations

Does Bun package a JS VM and runtime libs?

I think Nostr queries may actually be too fancy.

I remember that being discussed years ago and rejected on the basis that it would have the implication of relays having to depend on a relational database.

Maybe that is something that has changed or could be challenged?

Inheritance for Nostr event kinds is an interesting idea! What approach did you have in mind for this?

Simply creating a new Kind B that “claims” to inherit from Kind A doesn't work, as Kind A clients wouldn't recognize Kind B events by default. This isn't real inheritance.

I guess a true inheritance could be achieved by using Kind A with a special tag (e.g., [w, "application article"]) to indicate a subkind. This creates an inheritance framework for kinds.

- Kind A clients could render all Kind A events, ignoring subkind-specific properties

- Subkind-specific clients focus on their relevant events

If we want to go one level deeper, we could simply extend the tag (e.g. [w, subkind, sub-subkind]). However, I’m not sure if that would ever be necessary.

This method is backward compatible and pretty straightforward imo.

Would it work for your use case?