dww6…pdnf

Overview Articles Media Highlights

But things like access control, relational data, collaborative document creation, heavier datasets, or anything that requires a solution to the double-spend problem become very awkward (or impossible) to model on pure nostr. A simple example of this is lists. Not only is it common for a single user to mess up his follow lists because of a lack of consistency between clients or devices, but commonly requested features like shared ownership lists immediately result in a huge increase of complexity, either on the key management side or on the data structure side. Both of these problems are difficult to solve on nostr due to lack of consistency — keys can't always be reliably or safely shared, and linked data structures spanning multiple events by different authors can be hard to assemble reliably.

Nostr can be an everything app, but I think that means something very specific. Nostr can represent data types from pretty much any domain, but it can't actually support all the semantics needed to build any arbitrary system.

It is very common and almost inevitable for a single product to have both lots of category 1 and lots of category 4 and some % of category 2 & 3.

Minimizing technical /dev lingo

The first being that WebSocket is a streaming API and streaming API for everything is a bad choice. Mainly for 2 use cases:

  1. 100% Delivery is the most important problem

Duration of Adjustment Period: The adjustment period varies from person to person but generally lasts a few days to a couple of weeks. Gradually, your body becomes accustomed to the new sleeping arrangement, and discomfort should diminish.

So why not both? Group messages should be encrypted, and they should be stored on a particular set of relays. Again, assuming the relays used are trustworthy, this fixes both privacy and deliverability problems, because it's very clear where messages posted to the group should go.