I was just talking yesterday about wanting a PoW system to overcome this. I don't think BIP-13 is the correct solution to this though. I think it should be a PoW computed over just the pubkey and a nonce, so it can be attached to any event (in a top level attribute not covered by the signature, though that might require relay cooperation...)

You tricked them into unwittingly doing the Lord's work 🙏🏼

I actually want to see it on kind 0 (or at least, it should only be over the pubkey + nonce, it could still be attached to kind 1s though).

On kind 1s, a spammer and a legitimate user are on completely equal footing, whereas on kind 0, the spammer needs to regenerate a new POW for every new account (once it gets blocked) and a legitimate user only needs to generate it once, which means the legitimate user can invest more into their single proof.

I've been warming up to the keys.band method of signatures which is time based approval, *with history/audit. Possibly something like this would work, you approve everything, but have the ability to go in and audit/modify the list of relays that have been approved.

I support this and would love to build a kind1 POW client someday

You have to put some effort into it, but once you gain some followers, you'll get more engagement here than on X. Perhaps more than on the Fediverse too, or at least higher quality.

Hello sir

If I'm spitballing this, surely somebody else has already thought of, and implemented something like this (or likely, better)

If I'm spitballing this, surely somebody else has already thought of, and implemented something like this (or likely, better)

IMHO this would require a distributed content delivery system. A "video" would be a json manifest contain a list of content ids (sha256(content)) for different chunks of video data, possibly in multiple resolutions, and a list of recommended content delivery servers.

Content delivery servers would have a standard API to query download stats on content, to give people a fighting chance at estimating popularity of their content, and lightning integration to monetize downloading data, as well as upload and retaining it.

As I see it, content delivery servers would have a variety of policies and serve over HTTP/HTTPS (don't really need https since the client can verify the data by its hash upon download), but typically they would charge something small to upload, and use a LRU system to evict content, except those that have been prepaid to be retained (to a certain number of downloads and/or expiration). Stale data may enter a state where interested users can still download for a fee, and those fees may drive servers to retain them longer.

As much as I'd hate to see ads creep in, content delivery servers could help people with no bitcoin view videos by serving ads before permitting clients to download non-ad chunks (clients could of course download and discard these ads, as adblockers essentially do on youtube today)

I'd also like to integrate webtorrent but that has some severe privacy compromises.

I guess conceptually these would be very much like relays, but for chunks of data identified by their contents. Nostr would point to these chunks of data by content id.

Servers should probably also facilitate discovery of other servers by region, for instance. Admittedly it's not exactly in their interest to tell you about other servers (unless owned by the same entity), so it couldn't be the *only* discovery mechanism.

Other nostr content besides just videos could be served this way of course.

IMHO this would require a distributed content delivery system. A "video" would be a json manifest contain a list of content ids (sha256(content)) for different chunks of video data, possibly in multiple resolutions, and a list of recommended content delivery servers.

Content delivery servers would have a standard API to query download stats on content, to give people a fighting chance at estimating popularity of their content, and lightning integration to monetize downloading data, as well as upload and retaining it.

As I see it, content delivery servers would have a variety of policies and serve over HTTP/HTTPS (don't really need https since the client can verify the data by its hash upon download), but typically they would charge something small to upload, and use a LRU system to evict content, except those that have been prepaid to be retained (to a certain number of downloads and/or expiration). Stale data may enter a state where interested users can still download for a fee, and those fees may drive servers to retain them longer.

As much as I'd hate to see ads creep in, content delivery servers could help people with no bitcoin view videos by serving ads before permitting clients to download non-ad chunks (clients could of course download and discard these ads, as adblockers essentially do on youtube today)

I'd also like to integrate webtorrent but that has some severe privacy compromises.

I guess conceptually these would be very much like relays, but for chunks of data identified by their contents. Nostr would point to these chunks of data by content id.

Servers should probably also facilitate discovery of other servers by region, for instance. Admittedly it's not exactly in their interest to tell you about other servers (unless owned by the same entity), so it couldn't be the *only* discovery mechanism.

Other nostr content besides just videos could be served this way of course.

Someone *must* be working on a nostr-based youtube replacement, right?

Odysee? Kinda?

I think I just got a boner.

Post approvals for n/VIDEOGAMES

Ok I caved and got kiwibrowser on my android phone so I can install nos2x and actually approve posts here

I still main Amethyst but I promise to check often. Wish I could just turn off this post approval business. If its any consolation when you post into a Nostr group your follows see it in real time with the group linked in the UX so its not like nobody saw it. I just need to approve posts so people browsing the group see it too