Here's a simplified visual presenting why, among various other reasons (other visuals), DNN will succeed / has the best chance at achieving mainstream adoption, in comparison to all other protocols, and the reason for a bunch of domino effects that would reuslt in an exponential growth.

Made/setteled on a DEGA logo (been bugging me that I didn't make one for a long time)

Maybe I understood it wrong, or missed something, but NIP-29 is bad. If I make a group chat, I wouldn't use it.

Happen to talk to someone on vrc about nostr, gave them jumble as the best thing they can use to make an account and get started. They made an account (nsec / no download of the backup file, just to see things), and for some odd reason, they said when they tried to post they were told to login into github or gmail (and i'm thinking where did those options come from???). Couldn't see their screen unfortunately, but yea... not sure what happened there.

Copyright/IP/Trademark laws, a funny and interesting but headache-induced system.

"well, it was working on my pc at home" Hopefully this time around, on my friend's pc at a cafe with an aggressive internet connection, demoing DNN will work this time during the weekend / third time's the charm x3 (this would actually be the third attempt x3)

Small update to PWANS, considering the DNN policy changes. Decided not to be a weird wallet with forced event-y variant of the address and break interoperability with other wallets, it now just shows both native segwit (for dnn) and taproot (for nostr social). https://files.catbox.moe/era36w.apk

There's two projects I want to make, that i wanted to make years ago, now possible because of vibe stuff, but way later as they aren't that important in comparison to the current projects I'm doing. One is... of the adult kind... The other is related to DCA, but dynamic (so instead of dollar-cost-averaging, it's dynamic-cost-averaging).

DNN database size optimization: Example: 300 blocks Before: 50 MB After: 16 MB After after: 650 KB (Of unrelated self transfers in the eyes of DNN) Could make it smaller/zero, but then I'd have to add junk to Bitcoin via op_return (very tempting), but I don't want to do that.

Trying to make a Signal account. Signal: Signal couldn't send an SMS code because of issues with the SMS provider. Guess I'm not joining Signal unfortunately.

Realized that DNN doesn't need op_return, so considering i see that as mostly spam and doesn't full for any DNN need, i'll add a new rule to the policy to reject self-transfers with op_return data. This will make DNN even more lightweight =3

Some one replies to me "no that's not possible" me replying back "sure it is, we've already done it" them replying back aggressively "no it's not, you don't seem to know what you're talking about" was about to reply back with more clarity, but paused... looked at their profile, their replies, "ah, they're a troll wannabe trying to be popular through conflict". Ok, didn't reply and muted the account. Peace restored x3

One bug fix led to another bug fix led to another bug fix, led to a structural design flow that had me brainstorm a fix that I'm now implementing in DNN. 1. There'll now be no rule, on DNN, that requires a minimum fee per transaction 2. Transactions must be conducted using Native SegWit (P2WPKH) One rule removed, one rule added. Reasoning: I wanted to keep DNN nodes lightweight, and considering taproot doesn't contain information about the input part of a new transaction, only its hash id, meaning the node would have to store all transactions of a bitcoin block, resulting in running a full bitcoin node basically, but from a different starting point, that didn't feel right to me. Native SegWit has send/input information in its witness data from what i looked into, meaning there's no need to store old and barely related utxos, so that's why only Native SegWit. Regarding no minimum fee per transaction, well, because that information isn't found in witness data or anywhere else aside from looking at the old utxos, so considering that, and the min fee rate was 1 sat/vByte, i'd remove that rule. It's still a deterent to spam attacks of 0 sat fee rate, as most blocks are filled and that'll be more so the case as time moves on. I'd now need to also update PWANS to derive Native SegWit address types from an nPub instead of Taproot. With all of this, i think we're about to reach gold / no more fundementally breaking bugs or structural design flaws. All that's left is testing, and once things are nice, i'd imagine a code cleanup is in order, and then code audit+refactor where needed, more testing, and DNN node would be golden =3

The issue isn't a store not hard-filtering (not allowing them to be published) low quality games, you'd piss off the devs and the players that way (as we've seen in the past), but rather it's not providing the tools and systems necessary for the market to handle that curation effectively.