Wireguard.. I cant live without that and no way could that be rebuilt with nostr.

Clock.. doesnt (shouldnt) be sending data to servers, but possible for storage of lightweight preferences. Id want that to be encrypted.

Assorted apps reading REST based json APIs, some GRPC. These also wouldnt work well via nostr due to protocol bloat. That includes apps like Fountain for podcasts.

On the flip side, apps that need some authentication to identify would benefit by using nostr login vs email addresses or as an option in many cases. But bear in mind, the more data you tie to a single pubkey, the more that is collated about your life and behavioral network usage patterns. So thats a double edged sword

Reply to this note

Please Login to reply.

Discussion

I can't see why Fountain couldn't? Especially with the new NIP-97 proposal. We'd just need specialized relays to host this data.

We can have multiple pubkeys and use them for different apps. I may not want certain data to be co-mingled with my public profile.

Actually yeah I agree on fountain being able to convert to nostr for some of its app content

- boosts

- comments

- prefs ( followed shows, boost and stream settings )

The podcast content itself stays hosted where it is in binary form along with data in RSS feeds

Streaming sats probably wouldnt make sense to route through nostr as it wouldnt add value, and would be bad for relays

Streaming sats on the backend is probably just a constant stream of invoices being created and paid. These could be Zaps?

I dont mind application preferences being local settings.