Damn, I didn't know I had, *checks balance, 100,000 BTC I should start hiring 100 devs to finish my projects, should be done with 10 project by the end of the year xD Low-IQ decision = Implementing BIP-177 High-IQ decision = Not implementing BIP-177 Sexy High-IQ decision = BIP-188 (because apparently a bip needs to be written to not make bad decisions =P)

BIP-188: The Sat Symbol

View quoted note →

The UX for setting up/using multisig bitcoin wallet is horrible on most wallet apps, wolpus-christ.

I just realized a very useful thing I can ask AI to do: "Tell me the red flags of this ToS" Finally, some users can overpower their "I'm not reading all that shit" x3

Right, the changelog (it's not just making an android build): View quoted note →" target="_blank" rel="noopener">https://image.nostr.build/94d92db393a03daca163ddfe7ad4ff0e597ae9399d2ed5a9b8eefbf38d3874b1.jpgNOSTR_0

I noticed Primal used 'have the app play music on loop forever so the app doesn't get killed by the OS' trick. It's funny because i learned about that 2 days ago and opted not to do it x3 It's a shame though that only things approved by google, and the average user can't do anything about it, can only allow apps to always run and not get killed by the OS after a time. Anway, update on PWANS: After a lot of back and forth (and complications because this thing is basically web+native. Honestly I want to do native only later, but it is what it is for now), I'm comfy sharing the apk for pwans now for anyone to test. https://files.catbox.moe/p7ddu4.apk (use fresh keys / don't import your personal nsec/seed of course (unless you're feelin risky ;3), since i didn't update the repo with the android code yet, well, and it's been a while since i updated it =P, so you can't verify the code is clean/safe/etc, verify don't trust yadayada, will do it later)

1. lmao x3 2. What DNN brings to the table: No expirary for the Certificate, and no need for the co-signature of the Certificate Authority =3

I wonder when they'll kidnap the most evil of our current time. Ah, wait, a slave can't kidnap their master/s. Oh well. (or masters can't kidnap themselves, however you want to look at it / whichever is which). Of course i'm talking about a plot of an anime. of course.

I was going to have no drm like gog/itch for DEGA, but i figured out a solution that would reasonably satisfy most devs and not increasingly annoy and deter customers. It gives a 'yes' answer to the question 'Can there be a solution that is offline but not that easy to bypass by the average/casual user (still crackable like Steam's DRM and the like), does not annoy customers, does not rely on a central authority (single point of failure), and have it as an option?'. Will call it DRV as in Digital Receipt Verification as opposed to DRM. It'll be some time until its developed, but the path is now there =3 The picture is the text i'm using for the marketing post, since this is a touchy subject.

Test? Neat, I'll most likely share a link to the apk for pwans for anyone interested in testing

I think after finishing DNN and releasing it (v0.1), which is soon from what I can guess (along with the Jumble fork and the browser fork, maybe with a brave browser fork), along with the updated PWANS and its native app version, where efforts then would be just about marketing DNN, while I really want to work on decentralized CDN and decentralized ads and how I invosion it would work, I should go back and put full effort into DEGA again (finish the design, finish the technical and general documentation, then start developing it) along with updating/refactoring DEG Mods to match the structure and flow of DEGA. The pause on DEGA came because of the idea-spark of DNN and the opportunity that came from AI to make it a reality, so I didn't want to waste it and focused on it. After DEGA's initial release is done and DEG Mods gets its refactor with a few extra additions, both of which would be protected with DNN of course, I can focus back at and start workong on the ads and cdn projects, which would benefit DEGA and DEG Mods of course. View quoted note →

@makomichi the wolf of weeb street got reference material for your wolp productions =3. Mange: Hitoner

Username and password v2

Realized there would be a complication with DNN when there'd be a desire to lower the min fee rate from 5 vByte to something lower, and doing so will cause headaches to fix. Simple solution: Min fee rate rule should be change from 5 to 1 sat vByte and shouldn't be changed. Result: No need to change this rule anymore, lower cost to entry (but also lower cost spam but still relatively costly). No more headaches. Win-win. (Also I've begun working on that username password v2 =3)

How easy is it to get a DNN ID/TLD? As easy as this: send money to yourself, then claim. Side note: I do want to wrap/package this signer as an android app and utilize keystore (so it'll supposedly be as secure as any other mobile signer). At this point, should it still be called PWANS? Maybe PWANS Native? PWANNS? I think i'll keep the original name and have a bs thought of the N in it is both Nostr and Native x3

Ending and starting the year by giving you a smile x3

BUGS & HASH BUGS & HASH BUGS & HASH

I WAS going to have fun with making 'username password v2' today, but i noticed/realized a snag in DNN, where sometimes the input UTXO might be older than the bitcoin block DNN's genesis block is anchored to, and a DNN node wouldn't have that data, and realizing transactions could come from bitcoin block 0/genesis, i was contemplating and figuring out a possible solution: -almost no node indexes transactions for querying, so that's a bust -i didn't want dnn to rely on electrum servers, small decentralization element + trust factor, so that's a bust (last resort) -i could grab a minimum of block data, and while that's a lot smaller than downloading the full node, it's still kind of big and getting bigger with time, so that's also a bust -i did figured out a super-nice trick, but because of market dynamics, this would put a weird limit and create ux confusion So, after all that thinking and testing, what's the end solution? No headaches, hard limit: Self-transfers with an input utxo found before the bitcoin block that dnn's genesis block is anchored to will not be accepted. For most (99% and growing to 99.9%) won't be an issue, and if it does become an issue, the cost is just another self-transfer and they'd be all good. Either way, after this, i'll see if i can have a detection mechanism for users to be aware of if they're doing a self-transfer for the purposes of acquiring an ID in DNN, to just have that nice UX warning so they don't hit that small road bump.

AI love. A comforting falsehood. Reminds me of Beyond the Aquila Rift episode from Love, Death & Robots, though without the care of the monster but a mathematical conclusion so it's even colder than that. (This is assuming we're not dulluding ourselves of being something other than a structural logical outputs and conclusions like AI)

Worked today on figuring out methods to prevent a spam attack vector on DNN node relays, and on the way improving one part's UX. 80% done, 20% tomorrow (it's almost 4 am =P) A bit more testing after that, then I want to work on 'username and password version 2' and have fun with that (it's been on my mind for a long while and i really want to do it x3), basically a fun but productive break before i move back to the boring stuff. Side note: While thinking of that username and password v2 thing, I realized there's a security and privacy issue with with that process in general for everyone (extension or remote signer or other), a trust factor between you and the nostr client you're using, where even if you go 'one approval per any action' and have no auto-approvals, so they can't sign something on your behalf maliciously, they could potentially read what you decrypt. Yes open source and people would know etc but there's a delay, and that delay can cause damages. I already thought of a quarter-baked solution to this (something about having a user-generated/controled layer between the user and the client where only it renders the results and handles more approval sequences), but my plate of things to do is already overflowing so i won't be doing it x3 Maybe in the future / hopefuly i remember this issue.

I think the interesting thing about DNN is the supposed 'con' about it, there being no ability to transfer IDs, and that's actually a 'pro' thing. DNS and all other attempts to be an alt to DNS has: Unique (scarce) names + human readability + human memorability + human meaningful This combo results in the need for transferabilty (adds complexity) and figuring out solutions ot the squating problem. DNN removes the uniqueness (scarceness) and human meaningfulness out of the equation, removing the need for transferability (simple operations) because there's no need to keep track of transfers, and not needing to worry about squating because the ID you get are readable and memorable but not meaningful. This shift in perspective solves scarcity and complexity of such naming systems. In the eyes of DNN, unique names (not IDs) and transferability is basically a 'con', which is kinda interesting and maybe a bit funny x3