Recently, I started implementing encryption in dvmcp using NIP-17, which utilizes NIP-59 (gift wraps). Gift wraps have always been criticized for being spammy, as there is no way to limit the spam factor by filtering or performing other spam prevention stuff. This is because gift wraps do not reveal any information; they can be anything, making them an unlimited spam attack vector. As a result, just a limited amount of relays accept them. This is why you need specialized relays to use NIP-17 successfully. As far as I know, there aren't many, with 0xchat relay being one of the most specialized.

When considering how to integrate gift wraps into the relay behind dvmcp.fun (which is public and accessible to everyone but not a general use relay), I thought the best way to handle them, given the ephemeral nature of dvmcp messages, would be to use the same concept of ring buffer storage I created specifically to handle ephemeral events. This way, I could receive as many gift wrap events as needed without polluting the relay's database. The events would automatically and efficiently evict themselves when the ring buffer's limit is reached.

Ring buffers are quite interesting. They have a limited capacity, and when they reach their maximum capacity, they start to overwrite entries, typically in a FIFO (First In, First Out) manner. The oldest entries are overwritten by the newest incoming ones. This means the first entry in a ring buffer will be overwritten when the limit is reached by the first entry that surpasses that limit. This is useful because, knowing the frequency of the messages you are receiving, you can roughly estimate how long an entry will stay in the buffer. You can ensure a time-to-live (TTL) by increasing or decreasing the size of the buffer. For example, if you want an entry to live for 10 minutes in your buffer and you are receiving 1 note per minute, the size of the ring buffer should be 10. The first entry will be evicted with the 11th note received in 10 minutes. Of course, this is not always predictable, as the frequency of receiving notes may vary due to bursts of notes. To keep the average TTL of notes in the buffer, you can adapt the size of the ring buffer. If you are receiving 1 note per minute and suddenly start receiving 2 notes per minute, you can increase the limit of the ring buffer. Alternatively, you can create a second ring buffer to avoid dynamic memory allocation, which is more 'expensive' than creating a new ring buffer. If you have a ring buffer with a size of 10 and are receiving 1 note per minute, trying to keep an average TTL of 10 minutes, and suddenly start receiving 2 notes per minute, you can just create a new ring buffer with size 10 and start filling it. This will maintain the TTL at 10 minutes even if the frequency doubled.

Why am I telling you all of this? I have an idea and would like to hear your thoughts on whether it seems interesting. The idea is to create exactly what I described: a specialized relay for secure communication that uses ring buffers to handle gift wrap events where the events are treated as ephemeral events with a TTL. This way, you can offer a relay that will keep gift wrap messages for 10 minutes, for example, and can adapt to the demand dynamically and efficiently. This relay is not intended to keep messages forever, so the caveat is that you will have to be online to receive the messages before they are evicted. The benefit is that it can be much cheaper to have a relay handling gift wraps, as the storage requirements are less. This could improve the robustness of the network when distributing gift wrap messages, allowing for many of these small gift wrap relays to exist. You can connect to them to collect messages that are for you and then store them as you like if you need it. It also allows for ultra secure private communication for real time chats. If keeping the messages for a longer period is not a requirement and you just want to ping someone to see if they are online and maintain a conversation, this is a very private way to do it, using gift wraps as ephemeral events.

I have some more ideas we can apply to this concept, but I'll stop here as I would love to hear your thoughts. Does this make sense, or is it bs?

Thanks for reading!