I don't like new event kinds. They make building a nostr client more difficult.

I'd like to build a gundb-like universal database on Nostr where you write to filesystem-like paths such as group/[id]/messages or group/[id]/name instead of defining new event kinds for everything that could expressed as a path. https://github.com/gundb/gun

Nostr is not going to be an "everything app" if you need new event kinds for everything.

I'm quite busy improving the very basic features of Iris, but I'll try to find time for it at some point.

Reply to this note

Please Login to reply.

Discussion

NosDAV could be a useful addition. I like Gun, but I have found it can be resource intensive sometimes, and hard to debug why.

https://nosdav.com/

Ultimately, nostr can interface into many different persistence mechanisms, with just a pointer on the relays.

I'll take a look.

GunDB is a great idea, but the implementation was very difficult to work with when something didn't work and you had to look under the hood.

Also the protocol was such that making your own implementation was quite difficult. But definitely the concept is good.

I did some testing with gun DB in the past, didn’t have good experience with it due to performance issues.

nostr:note1gam822lz08ae252dstr3uc6ag3xkggzun4qj95wmg3a997ww0w8qzcl3za

I also had issues with performance and reliability.

But in the old Iris which used gun, you could easily delete messages, unlike and un-repost!

And you could follow / unfollow people without rebroadcasting your whole 100 kb follows list, which might even overwrite some old version and lose follows.

With the reference gun implementation, clients would also replicate data and sync both ways by default.

You don’t need to implement every new kind.

Just implement NIP-31 and 89 and let the ecosystem flourish in all directions.

I want to add new stuff like group names and pics, maybe share webrtc metadata, and I don't want to have to specify a new event kind for it.

When you want to do something new, would be easier if you could just do nostr.set('group/[id]/name', name) for example. If you want to build something complex like a mmorpg on nostr, that becomes even more critical.

You could discover all data on nostr by just browsing the file tree, with human readable directory names and nested structure instead of arcane event kinds.

You could update a single value on a list without sending out the whole list and risk overwriting another version that wasn't synced.

You could even easily unlike notes (nostr.set('likes/noteId', false)), and wouldn't need to separately implement delete event handling. That's how Iris used to work on gundb.

Actually tag-replaceable events already enable saving data to a "path", but not directory listing. While relays don't support dir listing yet, I can build a client side API prototype that subscribes to all tag-replaceable events by the user.

When you want to do an aggregate directory that shows writes by all your follows for example, relay side dir listing support becomes more important.

There's so much work to be done with even the basic social networking stuff, but I'll try to get a simple file explorer proto done at some point.

Strong disagree. But you do you :)

Meh, how large can a js number be?

You'll need a unique way to id a unique kind of data structure anyway.

Might as well roll a big random event kind and just go with it without asking

anyone.

Unless relays reject unknown kinds >=40k, it should be easy to find

unused kinds. And client side error checking would be essential anyway.

Is your method essentially different? Would those paths be reservable?

I miss Gun too. I wish you continued your Rust implementation. It could have become the main implementation above the js one pretty easily!

I love how #gundb works... But stopped using it until it's (better) maintained and some bugs and strange behaviors fixed 😟

Started a small fun project #miniGun to create similar base features and learn how gun storage, listener, ... works and learn to code

Once you used a decentralized global graph database… it’s hard to go back to anything else…

i think thru adoption new event kinds evolve the protocol allowing it to potentially always change

nostr:npub1g53mukxnjkcmr94fhryzkqutdz2ukq4ks0gvy5af25rgmwsl4ngq43drvk

Help, stream ia still dead... No input / send in DMs and no chance to switch between follower and global stream .

Fixed now... Strange behavior / bug. Looks like ui parts invisible like stream switcher...