does PoW relate to time spent by ^2? as in, a 29 PoW key would take that same system ~89,608 seconds?
)
the same place it would be stored even if it were in IPFS, servers. computers plugged into the network.
exactly that. also note the 8 links at the bottom to his elaborations on specific topics therein.
I'm definitely not here to shill for IPFS, just pointing out it was a design goal of that system. one of my favorite things about #[6] is his series of IPFS rants. only someone who was deeply interested in IPFS working could have tried it enough to get such a deep undestanding of its weaknesses. I have a similar experience.
the true innovation is the dissociating the verity of the content with the service provider. previously, the network effect drove returns and power exponentially to the party that owned the network. so in the case of twitter, they owned the underlying infrastructure and it didn't make sense to think of decentralizing twitter. the network effect was their seigniorage, the pay off for owning the network.
and just as bitcoin takes seigniorage out of the hands of centralizing elites, nostr takes the network effect premium out of the hands of the service provider and returns it only to the protocol. the more people use the protocol, the more protocol users benefit. service providers are thus incentivized to provide good services they can be paid for, but not to gatekeep. it's an exciting dynamic and why this model can work to induce a bottom up revolution in the flow of information.
IPFS, with all its failings, at least accomplishes that narrowly defined task. nostr abstracts that sameness to the content itself, such that when presented with an event, you can verify, not trust, that it was published by the indicated pubkey.
right on! for starters I have very little public facing material yet. the basic premise is to represent a feed as a pubkey, where each item in the feed is mapped to an event. there is already working POC of this created by @fiatjaf.com at https://github.com/fiatjaf/relayer - check the rss bridge subcomponent.
I am working right now to get my own implementation up and working. for the moment, you can see a half-assed attempt here: https://nostr.io/podcasts the page is poorly formatted, and I'm still tinkering with every aspect of it. but the basic concept is there. I aim to support normal RSS feeds along with podcasts. you should see the mp3's in those podcast episodes as media controls rendered natively in your browser.
at the same time, I'm working on a nostr backend, where you can get a link to an RSS feed of your events. look on the left side at the RSS icon: https://nostr.io/p/b17c59874dc05d7f6ec975bce04770c8b7fa9d37f3ad0096fdb76c9385d68928
and finally, I have a PR into the nostr protocol github to add "resources" to nostr events. I am already using that feature in my demo podcasts link, but it's not part of the protocol https://github.com/nostr-protocol/nips/pull/43
I'm happy to talk further at length about any aspect of this that you may be interested in.
oh derp, I meant to reply to #[1] who said something about an influx of users once damus gets approved in the regular app store.
and I'm just not sure what to think about it. there will for sure be a much lower barrier to entry, but I'm not sure how many people are interested enough to start using another social media app, but were blocked by the poor state of nostr clients.
nostr.io already respects kind 5. and so far, when you hit the rss URL it generates the feed from the db each time, so deleted events would disappear from the feed