Is any company posting BTC/USD conversion rates (and other assets) as Nostr events?

Reply to this note

Please Login to reply.

Discussion

Too bad it posts as kind 1, which is impossible to filter and use in the app.

Maybe they can ship as another kind just for apps to get the latest and historical prices on a single Nostr filter?

I am the dev, what kind do you like?

Writing the NIP right now to clarify what I need.

Basically a way to convert $BTCUSD ticker to the value on any Nostr post. Which means users must choose a trusted partner to provide the data and the app must filter by tags with that ticker.

More soon.

Might as well consider #btc to #gold .. because USD is just another currency .. commodity to commodity is a better way to understand things ..

If you do want to project currencies than cents per #Sat is probably right unit ..

Units are important.. they stick in the mind ..

Bitcoin became a store of value because we talk in terms #btc .. if we talked about #sats in all Bitcoin education , it would have become a currency ..electronic cash as envisaged by #Satoshi

Keep me informed, thank you.

Looks good to me as a producer.

Thank you for mentioning Bitagent as "Price Provider".

In a few hours, midnight UTC+1, there will be a first kind 1892 event ... 🙂

You might want to have your own relay :)

Maybe, but let's see first how it's going on with the nip-85 ....

Feel free to suggest any changes that might make your work easier.

Check kind 1009

Nice! I hate the positional args though :)

I think we could benefit from a replaceable to get the latest.

https://github.com/nostr-protocol/nips/pull/1658

Limit 1

What if I want to make a dashboard with all of the latest prices? That would have been a massive filter :)

I guess so, the positional args are for ask/bid/low/high so you could make candle sticks

Have you considered a more generic approach for time series in general?

This could be used not only for financial data but other things, e.g., sensors, etc

We can have other event kinds like those for other types of time series. But making one kind the generic kind for everything is bad for filtering and storing.

Agree!

Would this not be a usecase for DVMs?