This is great, I have been using the app for about a week, and now it's my daily driver for music View quoted note →

GM!

Hey, how's it going? I'm going to share some stuff I was working on this week. I started playing with Rely, the relay framework by @Pip the WoT guy which is pretty good and lightweight. It's also super customizable, which means you have to create your own logic to handle events and filters. I was wanting to find the best way to handle ephemeral events, which are events that are supposed to just be relayed and not stored. I realized that a time-to-live feature would be beneficial to make them more robust, as they could be found in relays during a specific period of time, like 5 minutes for example. While researching ways to implement this, I realized that having a TTL would most likely introduce overhead in operations. So I decided to go in a different direction using circular or ring buffers, which are very interesting for the ephemeral relay use case. Since the buffer has a fixed size, when the maximum size is reached, it wraps around and starts to overwrite the oldest events. In this way, the memory allocations are more predictable, which results in more performant code. Also, using a ring buffer means that the time events will live in the relay and can be queried is more unpredictable. There isn't a defined time they must be stored, they just stay there until their time arrives and they're overwritten by a new incoming event. From my point of view, this is a totally fine drawback since ephemeral events are just supposed to be relayed, but this adds a layer of robustness as the events could be found stored in the buffer after their publication. With this in mind, I coded different versions of the ring buffer, iterating over it and benchmarking the different implementations. I ended up with an atomic ring buffer implementation that's very performant and lightweight, thanks to @Pip the WoT guy as well for the suggestions for the code and pointing out a race condition, it was fixed. Now the code is available here

GitHub

GitHub - gzuuus/rely-lab

Contribute to gzuuus/rely-lab development by creating an account on GitHub.

with the results of the benchmarks. This was an interesting research project, and I'll be implementing this for the relay behind dvmcpfun as the new spec is based mainly on ephemeral events. I'll probably also create a Go library similar to eventStore to make it easy for others to use this atomic ring buffer implementation for relay storage, you can use it for any event kind if you want not just ephemeral. A part of this, I made significant progress in refactoring the DVMCP packages. The bridge is almost finished and the new specification have been implemented. However, refactoring tasks are not as exciting to talk about as the research into ring buffers.

GmGm

GM🌞

Earlier this week I started refactoring the dvmcp packages to implement the new spec, it's going well so far. ETA 2 weeks ✌

I had to touch a windows laptop today. I still feeling dirty

Nostr is gfy

Relays, bots, and DVMs are not the same. These terms are being mixed up recently, leading to clear confusion about what each of them represents. I’m going to share my perspective on what they are, and I hope this can clarify the vision for others or, at least, provide a good opportunity to better define them. A relay is "essentially" a dumb piece of software that just receives and sends notes upon request. I say "essentially" because there are some advanced and sophisticated relays that offer additional services like translation, spam filtering, etc. That’s fine, but it is still fundamentally a relay. A bot can be anything, it is an NPUB that can create notes, whether they are posts, responses, reactions, or any other type. Its operation is based on any conditions or instructions that the creator of the bot wants to implement. For example, it could listen for notes mentioning the NPUB of the bot, notes with a certain hashtag, or even other conditions like a weather station publishing weather reports and alerts. Bots are extremely flexible, and can be as simple or complex as you want. A DVM in the other hand provides specific functionality, whether it’s a translation service, algo feeds, public key lookups, image generation, or anything else. DVMs are also quite flexible, as you can abstract any type of computation behind them, but the key idea is that they use a standard way to access their services. Putting this all together, you can have an image generation bot that listens for notes mentioning its NPUB or notes with the hashtag #cats (or whatever you choose) to respond to those notes with an image. The bot will be able to use a DVM to fulfill its functionality, and both the bot and DVMs will utilize relays for communication and coordination. Bots can be complex systems that integrate multiple capabilities, while DVMs are more atomic component, with a single responsibility and a standard interface. One bot could use multiple dvms to handle its functionality.

Due to the recent and ongoing discussions about DVMs and the @fiatjaf intention to reset it, I wrote a proposal rewriting the nip, This is a starting point and, hopefully, it will make sense to others. If you are interested in DVM stuff, please read it and provide feedback

GitHub

Rewrite the DVM spec by gzuuus · Pull Request #1904 · nostr-protocol/nips

This is just an starting point for a rewrite of the DVM spec. Read it