Anime is a no life. Don't tell me otherwise.

So if I'm following, I should prioritize kind 10002 events, then content of kind 3, then p tags in kind 3. I won't be doing any complex scoring I don't think.

So on the hypothetical side of this, I think, if the relays in p tags were lists, and they were only used to fetch a user's kind 0 event and it contained a list of relays that were updated every time a client added or removed a relay, that should prevent rot while keeping all the extra complexity out of this, no?

I am not building a nip-35 client. I do not like the torrent specification in nip-35. I don't actually need a specification for an event type for this, and IMO most applications seeking to use nostr don't either. I am building what I'm building without submitting a NIP and without any application specific protocol implementations at all. This is something that a user should be able to subscribe to content producers with any existing nostr client and view with existing client software, such as an external torrent streaming application.

I don't like the specification for several reasons, first is that there are application specific tag definitions in the spec. A general torrent spec should not have an IMDB specific tag. It seems this is built with a particular application in mind to support someone's torrent client for piracy (and I'm all for piracy but what I'm building is not a piracy specific tool) and not for generally sharing torrents.

That said, I'm probably going to give users the option to publish their torrents as kind 2003, but in MVP initially, and later by default, notes will be published kind 1.

Well then I think the best way to solve this would be a tool that enables content creators to publish a torrent and then a note notifying followers of that content, and discussion about it happening in the replies to that content. I think this could be a censorship resistant way to distribute video content, podcasts, music, even images, and it separates hosting of media from relays, it makes the barrier to entry to hosting your own content very low, and allows basically anyone to begin hosting content for others and so democratizes content hosting. I think this is such a good idea in fact that I'm currently building software that does this as we speak.

Why would you want a relay to host multimedia content and deliver it? What are the benefits of that? To me, it seems like an added barrier to entry for a would be relay operator, if they had to host gigabytes to terabytes of video, audio and images. I know they don't *have* to, but relays existing that do that would really put a damper on usage of relays that don't.

I think it makes more sense to pick an existing censorship resistant protocol that is capable of distributing the media itself, and using nostr for the notification and discussion side. Something like, a torrent is published and a note is generated and published with a magnet link and description, and discussion happens in it's replies. I happen to be building exactly this right now as a solution to these and other problems, and if a relay operator wanted to also operate a hosted seedbox they could do that alongside their relay. Maybe I'm biased on this, but I didn't undertake my endeavor and then decide it was a good idea, I thought it was a good idea before I started building.

What do you mean nostr native? How would the media file be hosted? Right now I'm seeing media delivered via HTTP everywhere media is shared on Nostr, so would a delivery mechanism of the media itself over some other protocol, but notification and discussion of the media be exclusively over nostr, be a valid answer to your question?

Well it's up to clients to generate the proof of work required by either relays or other clients fetching notes, and to implement filtering for follows based on a proof of work if the user desires.

It's a difficult problem, because you can't have user defined PoW thresholds that their follows don't know about, it's really best filtered by relays. Say I have a PoW requirement that the note id must start with 3 0s, but a follow produces them starting with 2, I won't get his notes. If I trust a relay though to require it and if there's some way for a relay to tell a client what it's PoW requirement is, then it's not a problem. PoW doesn't really affect your curated feed positively, it affects spam to relays, and if youre viewing a global feed, it can be used client side to hide spam at the cost of hiding basically everything from relays that don't require it.

As far as phones doing the PoW, that's not really that big of a deal. Some relays might require a high threshold to reduce spam, and if a user is incapable of producing it in a timely manner he can just publish to other relays, and if I'm big on following him I'll fetch his posts there. That relay might have a spammy global feed but as long as you're only fetching your follows from it it doesn't affect you.

Thanks for the response man. I was trying to figure that out and I don't know the NIPs like the back of my hand quite yet. I've been following Nostr and dabbling with it since there were like 17 NIPs and the protocol was much simpler and keeping up with this stuff can be hard as it's happening fast, I need an RSS feed (or a Nostr bot?) to help me keep track of all the changes.

So there are 3 ways you can get relays to fetch from, the NIP-02 way, the way I'm talking about where they're in the content (and they're the recipient's relays, not a dump of all follows relays if I understand that correctly?) and the NIP-65 way? I ask because I'm working on something and I want to make sure to cover all my bases and implement everything I need to implement to satisfy users.

An aside, I quite like the NIP-02 way of storing them with one caveat: I think the field for a relay in the p tag should be a list of relays as this would help with censorship resistance. I really like a simpler protocol, and I like the idea of client side storage of feeds, I've actually got a client I'm in the very beginning stages of building that is focused largely on user definable client side feeds, but it is on the backburner in favor of a CLI utility that uses bittorrent and nostr to enable media sharing.

...? What would you like me to expand on? I've said what I said, is is there some particular detail you'd like to have a conversation about?

+1 for me. There's also a several XMR heavy hitters in this list if you can figure out who they are. Nostr has a thriving Monero community.

To both of you, you might be interested to know about NIP-13 which allows relays and clients to require proof of work before doing anything with a note. So no capcha or anything like that required, if relays began requiring this or clients began requiring it it would work just like hashcash for spam mitigation, I would like to see more nostr software implementing this.

https://github.com/nostr-protocol/nips/blob/master/13.md

Hey sorry to derail, but I have a question you probably know the answer to that is related to this topic.

Does gossip store follows' relays in the p tag of the kind 3 event or does it store them in the content of the note? I've seen some clients doing that and I wondered why that was being done as opposed to following nip02 properly.

Don't forget "90% of posts are reposts"

Yeah I know. So I've been following MW development since before Grin launched, and there's some interesting things about that. The original MW paper specified an interactive protocol with no programmability. It also required absolutely no historical data preservation whatsoever. Andrew Poelstra massaged the cryptography a bit and brought us the MW we know today, which does have programmability, at the cost of needing to preserve a range proof for every transaction forever, which in MW is called a transaction kernel. So you get multisig and all that good stuff (but no scripting, but there are ways to script with it nonetheless) but you lose that very powerful feature of needing only the UTXO set for full security.

I think that feature is the killer feature of MW, it is the trait that allows it to scale to the limit of the trilemma, you don't even need a block size if the chain doesn't grow forever, the block size is limited by a function of block time and network latency and not by transaction size. But we have to have multisig and that kind of stuff to do anything more interesting than plain cash, so here we are. I hope we can figure out how to build something that has both and I can see no fundamental reason why it is not possible.

https://github.com/brave/brave-browser/issues/37735

Brave is deprecating IPFS support.

What lessons can be learned from this?

Well, first off, that IPFS is effectively a failed project. I was and still am a big fan of IPFS, but anyone that's ever tried to integrate IPFS into an application knows how badly it is maintained. There are some interesting projects using it, such as libgen and various archives and libraries, there is https://github.com/mrusme/superhighway84#connectivity which is a pretty cool idea if you can get it to work. But overall for multimedia and general file distribution, Torrents have continued to work for everyone just fine. And an aside, if you've seen what protocol labs is up to these days as an IPFS user you probably feel like you need a shower.

Second and more importantly, we learn that we can never really rely on other people to maintain software for us. That goes for both IPFS and brave. You want IPFS in your application, well good luck having a low maintenance codebase. You want a browser that supports IPFS, well it works until it doesn't.

I'm sure you did man, youre one of the hardest working people I've had the pleasure of interacting with on this side of the internet. Using NIP05 to do this is a pretty cool idea like I said, I'm sure there's a ton more interesting stuff you've solved that you didn't talk about, I'd love to hear about some of it.

So I'm curious, you and I have both seen the terrible effect of admin fiefdoms in the fediverse over the years, you probably more than anyone else. You're not concerned about recreating that here? Turning relays into community servers, admins of community identities, youre not worried about block lists and flame wars and people getting booted from communities for having the wrong friends? A key getting blocked from fetching from a relay because their posts are on a specific "bad person" relay or anything like that? The fact that admins can't take your keys is wonderful, bit did you put any thought or work into trying to avoid all that mess from happening here?

Thanks I hate it.

Dramatic. Maybe I'm just not understanding. Looks like youre trying to recreate fediverse on nostr? Probably the best thing about nostr is that it isn't the fediverse. Why can't people just use hashtags? If it's any consolation, I don't get the point of NIP05 either, and I'd say it's cool youre using that, but I just fail to see the point of it. It doesn't appear to solve any technical problem at all, it's just silos on nostr, complete with feifdoms. I feel like the only thing that can come of this is that we get dragged back to an inferior user experience.

You can choose not to broadcast a note with a Monero payment, keeping g the tip completely private.

There's already a PR for this by nostr:npub1w4uswmv6lu9yel005l3qgheysmr7tk9uvwluddznju3nuxalevvs2d0jr5 that just needs to be merged, I think though it's a better idea for him to take over the project if he wants.

I don't think he's the one with the bounty. But, nostr:npub1w4uswmv6lu9yel005l3qgheysmr7tk9uvwluddznju3nuxalevvs2d0jr5 has a pull request for the app ID issue that I opened. I think retrnull is not interested in maintaining garnet, just like you said I think he wanted to release a proof of concept.

nostr:npub1w4uswmv6lu9yel005l3qgheysmr7tk9uvwluddznju3nuxalevvs2d0jr5 would you be willing to complete all the bounties at https://bounties.monero.social/posts/147/garnet-maintenance-sync-upstream-new-icons-resolve-amethyst-dual-install-conflict-etc create a release on your fork of garnet and collect the bounty? I don't think retrnull is going to merge PRs. You'd wind up taking up maintenance but it would be something you'd pick up some xmr for, especially since youre on nostr, I bet you'd get tons of Monero tips too that retrnull would be getting if he had a nostr profile. It looks to me like the hardest part is going to be sync with upstream amethyst.

Don't forget to change the xmr donation address in your fork if you decide to do it.