-
@ Water Blower
2024-05-10 23:07:42Here is a simple chart for developers to understand when to "Nostr Native" and when to "Nostr Integrated"
Definition:
Nostr Native: Uses relays as the only network layer and storage layer and business logic is 99%+ client side.
Nostr Integrated: Has in-house solutions and only connects partially to Nostr.
Both categories could be open sourced or close sourced.
| Features | Benefit From Network Effect | Don't benefit from Network Effect | | --- | --- | --- | | Contribute To Network Effect | All in Nostr Native | Recommend Writing to Nostr | | Harm Network Effect| Don't Write to Nostr and could read from Nostr | Should be in-house solution and not write to Nostr |
Category 1
If we think we should be all-in Nostr Native no matter what (like 99%+), we are limiting ourselves to only features that both benefit from Nostr and contribute to Nostr. This is a totally valid proposition as long as developers are consciously aware that they are indeed making a product within this category.
Pretty much all public facing social features fall into this category.
But, there are many products that need features that fall into other 3 categories.
Category 2
For features that benefit from Nostr but harms it, you are basically stealing data from Nostr without contributing back. My advice to is not write to Nostr at all and only read from Nostr if you have to do it, but you should minimize this product design in general.
Pretty much any massivly bot/batch job/pipeline generated data fall into this category. Machine generated data do not necessarily mean spam data. In the data engineering & machine learning world, it's very common to generate intermediate data in data pipelines for downstream analytics. This kind of data is huge and can also be purely textual. Don't write to Nostr relays.
Category 3
Is it even possible to have features that don't benefit from the network effect of Nostr and can contribute to it?
I can't think of any. But if it exists, consider writing to Nostr even if you don't use relays as the primary storage.
Category 4
These are features that don't benefit from Nostr and also harm Nostr if writing to it.
Slack style internal organization communication falls into this category. In fact, we want to actively prevent these features from having network effects because having these data in an open network might reduce their security.
Writing them to Nostr also harms the network because these data, encrypted or not, only have semantic meaning within the organization. Posting them to Nostr reduces the overall signal(value) density of the network.
Outtro
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.
Using this chart, you will know how to make wise engineering decisions that help your product design instead of harming it and help the network at the same time.