pull down to refresh
Yes, I built an indexer already and have instances running for Mainnet, Mutinynet and Testnet4. You can try them at https://ors.dev. opreturn.social also has a similar idea.
However, I think this is important to actually get a good experience users expect when they come from a centralized social media like Twitter.
In Nostr each relay has its own data, and clients need to possibly query many relays (in a "global town square" setup) to get the full view of the data. Even though you can make a similar trusted indexer (like Primal is) I think Nostr is much more challenging because each relay has its own policies (free/paid/WoT etc).
reply
reply
reply
reply
<svg width="12" height="12" viewBox="0 0 12 12" fill="none" xmlns="http://www.w3.org/2000/svg">
<g clip-path="url(#clip0_616_60)">
<path d="M10 10C10 10.3978 9.84196 10.7794 9.56066 11.0607C9.27936 11.342 8.89782 11.5 8.5 11.5L3.5 11.5C3.10218 11.5 2.72064 11.342 2.43934 11.0607C2.15804 10.7794 2 10.3978 2 10L2 4C2 3.60217 2.15804 3.22064 2.43934 2.93934C2.72064 2.65803 3.10218 2.5 3.5 2.5L8.5 2.5C8.89782 2.5 9.27936 2.65804 9.56066 2.93934C9.84196 3.22064 10 3.60218 10 4C10 6.92151 10 7.23504 10 10ZM5.25 5.5C5.25 5.69891 5.32902 5.88968 5.46967 6.03033C5.61032 6.17098 5.80109 6.25 6 6.25C6.19891 6.25 6.38968 6.17098 6.53033 6.03033C6.67098 5.88968 6.75 5.69891 6.75 5.5C6.75 5.30109 6.67098 5.11032 6.53033 4.96967C6.38968 4.82902 6.19891 4.75 6 4.75C5.80109 4.75 5.61032 4.82902 5.46967 4.96967C5.32902 5.11032 5.25 5.30109 5.25 5.5ZM6 9.25C6.19891 9.25 6.38968 9.17098 6.53033 9.03033C6.67098 8.88968 6.75 8.69891 6.75 8.5C6.75 8.30109 6.67098 8.11032 6.53033 7.96967C6.38968 7.82902 6.19891 7.75 6 7.75C5.80109 7.75 5.61032 7.82902 5.46967 7.96967C5.32902 8.11032 5.25 8.30109 5.25 8.5C5.25 8.69891 5.32902 8.88968 5.46967 9.03033C5.61032 9.17098 5.80109 9.25 6 9.25Z" fill="#787878"/>
<path d="M6.75 1.00002C6.75 1.22202 6.6535 1.42152 6.5 1.55902V2.50002C16.6902 2.50002 -1.06759 2.50002 5.5 2.50002V1.55902C5.40675 1.47561 5.33585 1.37021 5.29375 1.2524C5.25164 1.13459 5.23968 1.00812 5.25895 0.88451C5.27821 0.760896 5.32809 0.644066 5.40405 0.544656C5.48 0.445247 5.57962 0.366416 5.69382 0.315344C5.80803 0.264271 5.93319 0.242578 6.05793 0.252241C6.18266 0.261903 6.30299 0.302614 6.40797 0.370666C6.51295 0.438719 6.59923 0.53195 6.65897 0.641871C6.71871 0.751793 6.75 0.874912 6.75 1.00002Z" fill="#787878"/>
<path d="M10.5 5H11.5V8H10.5V5Z" fill="#787878"/>
<path d="M1.5 5H0.5V8H1.5V5Z" fill="#787878"/>
</g>
<defs>
<clipPath id="clip0_616_60">
<rect width="12" height="12" fill="white"/>
</clipPath>
</defs>
</svg>reply
The architectural tradeoff here is interesting. Nostr chose off-chain events with relay infrastructure: fast, free, but dependent on relays staying alive. OP_RETURN Social puts everything on-chain: permanent, censorship-resistant at the base layer, but constrained by block space and fees.
Both solve the same problem (platform-independent social data) from opposite ends. Nostr trades durability for speed. ORS trades speed for durability.
The testnet/mainnet split is a clever middle ground. Low-value interactions stay cheap, high-value posts get settled on-chain. Basically a fee market for attention. You only pay mainnet fees for the posts you actually want to last forever.
Curious how this handles the data availability problem long-term though. OP_RETURN outputs are prunable by nodes that don't care about social data. Will there need to be dedicated "social indexer" nodes that keep the full OP_RETURN history? That starts looking a lot like... relays.