if someone takes my hardware wallet somehow:
Freakoverse
naBobAbout
npub18n4y...zk9r
I guess I'm one of those #vtubers.
Having fun talking about general topics, vrchat/similar, and games. Also #indiedev #gamedev. You can call me: Freak فْرِيكٌ フリク (still learning Nihongo).
#envtuber #podcast #gaming #gamedev
Step 1: Make hardware financially inaccessible to most people
Step 2: They now have to cloud game with a subscription
Step 3: Control the customers, how they play, what they play, and how long, as you milk every penny out of them


The parent company of TheGamer will launch a new game mods site.
I'm veeery confident what future actions and decisions they'll take, it's like i have a crystal ball x3
Ok. Yesterday/today i did changes to the DNN node (and documentation) where it should be ready to start dealing with (hopefully) looking at npub addresses as the the identifier instead of an IP, and prepped it for the potential future that is Tollgate (and bug fixes).
Before I actually start implementing this in the forked browser with dnn support and test the flow (and if all's good there, i'd work on a daemon and Windows Services packages, iOS users will have to use a DNN support browser because Apple sucks), I want to do what i said before "Node peer discovery" first, basically "hey, i'm a dnn node, what other nodes you know? what other relays do you know? thnx, i'll have a copy of those and connect with them" and also "yo! i'm a node. Other nods add me plz" and "let me look at the data you have real quick... wait, yours is different than mine... how should we handle this? Ok look, i'll just take yours since mine is older"
Once that is done, then the DNN node would be technically complete.
There'd just be one page/system to do, which isn't related to the node itself but rather about choose the best node version and bitcoin node version (to avoid the shitshow that happened with bitcoin and give the market more power that it rightfully should have in such a situation).
What started as "I'll make a freedom Nexus Mods" because I got pissed, continues with (because I keep getting pissed x3):
"freedom Steam/itch/gog"
"freedom ICANN"
"freedom ID"
"freedom Twitter"
"freedom news/blog"
"freedom forums (even more free-er than current implementations"
"freedom comments"
"freedom streaming"
"freedom videos"
"freedom CDN"
"freedom chat" (direct, group, and communities)
"freedom point-of-sale" (this is a big one, one of the big pillars for DEGA's success)
"freedom email"
"freedom events"
"freedom ads" (this is also a big one, for the business side, and not done traditionally).
(there's a bunch more, but you get the idea, I'm always getting pissed to make these when the time is right / i can x3)
"I'm building a product" to "I'm building an ecosystem".
Some are done, and will be improve, and some aren't done yet, and some i haven't started yet.
And no, I'm not biting more than I can chew (the power of the global nostr developers and what's already built + AI + initial support + myself allow(ed)s me to do all of this) and all are related to and are interconnect with each other to increase each other's value and support the other, and in turn will decrease business risk, decrease running costs, and allows me to create other value items to sell and grow everything as I take decent chunk of multiple pies (markets). And all will be maintained / not abandoned like many others have for their projects (and it's because I'm taking strategic and business steps for their funding).


By the way... why hasn't anyone made a secure nostr key and and remote signing manager for umbrel or others, tied with a web interface for your phone or pc? i'd imagine it'd be the most secure way to do things in a hot/cold storage setup.
hopefully someone will make it (or me, idk, too much on my plate x3)
I think it's a good idea of a put a comparison table between DNN and all other past attempts that tried to bring about change to dns, and put that table in the readme of the project, which will help people understand the difference and potentially help with developer adoption.
DNN vs:
Nomen, Spaces, ENS (Ethereum Name Service), BNS (Bitcoin Name Service), Name Coin, Unstoppable Domains, Handshake, Starname, etc (anything else?)
I think I can also just bundle a lot of them that depend on another blockchain other than bitcoin.
(side note: What's interesting about DNN, is that it can be chain agnostic, and anchor to however many blockchains it wants, but i don't care about any of them and i'm just focusing on bitcoin at the moment, and others can add support for other chains if they want, as i don't see a need to waste time on any of them since bitcoin is the most secure and the most decentralized).
With DNN, the ICANN-DNS problem is solved, and I thought "someone else can handle the ICANN-IANA problem", and someone conceptually did, but I thought today "why wait for the implementation to then have DNN support it later?" I'll just go ahead and support it now and build/playtest with it as soon as possible.
DNN will actually be a non-hostile full ICANN (DNS and IANA) alt.
With adoption, the internet will be half fully decentralized/permissionless/censorship-resistant.
What's left is the ISP problem, and I'm hoping, with time, Tollgate will be that solution. Once it reaches 50%+ adoption, the internet will fully be properly decentralized/permissionless/censorship-resistant.
The other issues (CDN, ads, etc) are a breeze in comparison / would be fixed later.

I know I said I wanted to relax today, but an idea struck me and I think I'm close to figuring out a scheme to shorten nostr event/post address down to 30% (or 5% depending on the address), from their original size.
Meaning no more stupid long addresses of nostr posts when sharing them.
This is for those with a DNN ID to get the smallest possible share link/address. No more scaring people with huge nostr links.
Hopefully I'll figure it out x3
Still need to do a bunch more work on this, but I said I'd show magic by today, showcasing the latest state of DNN, and here it is:
What was done:
- Massive visual and UX overhaul.
- Updated the name/ID encoder (now shows fewer words most of the time, so even more human readable/memorable).
- Grabbing relevant events from other relays.
- Implemented the Awareness system (if there's a domain that's problematic, the node can mark it and not server it. Others can choose to do it).
- Updated the 6200 connection event to include a more complex support of connecting to servers (including delegating connection data to a server without risking your nostr nsec).
- Remove signer nostr connect.
- Optimization (the dashboard isn't slow/sluggish anymore)
- Fixed a bunch of bugs.
What was done (extra):
- Tested support of DNN on a nostr client and worked (on jumble.social fork).
- Tested support of DNN on a browser (lightweight one for now) to not only retrieve a website, but also verifying SSL/TLS certificate that's self-signed (no need to co-sign with the Certificate Authority).
To do:
- Double-check on re-org scenario.
- Node peer discovery, connectivity, auto self-discovery, and management as well as handling edge cases of conflicting data.
- Double-checking on TLS functionality working on the browser to the intended server.
- Detailed documentation of the project (a lot more than currently available, and on the node itself, including documentation on implementation on nostr clients and browsers, and down the line Operating Systems / specifically Linux distros).
- Set up pages for n0.0/n0 and b1m.0/b1m/b1000000.0/b1000000 to be nostr pages showcasing posts by different maintainers of different versions of DNN nodes and Bitcoin nodes (to solve the issue bitcoin has with which to best promote and use the market-decided node version. I don't want to have that mess with DNN, and on the way giving that solution to Bitcoin as well).
- Implementing the second part of DNN ID registration in PWANS (At which point this would be the tool to use to get IDs easily and manage them).
- Plan and develop and implement what I'm calling "username and email version 2" and implement it in PWANS alongside the jumble.social fork.
- Update the jumble.social fork to auto-discover a user's (with a DNN ID) relay list to have users finally establish proper connection with each other and significantly decrease the chance of missing communications (solves that problem on nostr).
- keep testing, improving, and fixing, until I'm satisfied with everything and have the DNN repo public for use and/or review the code and push PRs to fix it / contributors come and see the mess to fix and improve things bit by bit x3 (if that doesn't happen, I'll just hire one or two people to review the code and see where issues are and improve things, when funds become available), so that people can start running their own DNN nodes and expand the network / its decentralization.
I hope I didn't forget anything else to mention.
Now that my self-imposed obligation of sharing this today is done, and even though I want to continue, I want to relax and so I'll spend just one day, tomorrow, not working on any of my projects or others' (aside from normal work), because it's needed x3
"The node should be significantly faster now. Want me to also optimize the dashboard's block/anchor loading, or should we stop here for tonight?"
Fuck you AI, I'm not going to sleep xD
I see some videos about how AI, if used by a new company/startup that's fully vibe-code focused, is good for prototyping stuff but when it comes to production things go to shit real fast.
Generally speaking i think it's true, but also not at the same time.
How I generally do it at the moment:
Prototype for fun. Document.
Once you had your fun, research, document, then build (from scratch again) the product assuming production-ready use immediately, and constantly test and edge-case test, and load test.
That "document > research > document" part is basically heavy research and understanding the logic/system flows to keep the AI in the right track, and always test for production-level use.
And after a while, I'd have expert/talented human code-reviewers on it.
That's how I'm doing things anyway.
AI won't be magical for those aren't knowledgeable about the thing they want to make.
AI programmed DNN for me, but it didn't think of that solution for the ICANN-DNS problem, it didn't solve Zooko's triangle, it didn't think of the naming encoder system that's scalable, it didn't think of the adoption strategy, it didn't think of collision-avoidance with legacy DNS, it didn't create the UX flow of PWANS and think of the edge-cases of the eCash flow, had DEG Mods been made with AI it wouldn't have known or pushed for various UX enhancements and censorship-resistant systems.
AI is great with coding, it's saving me tens of thousands of dollars, but it's no where near the mastermind.
Records of Ragnarok
Season 3
6 episodes in
IM NOT CRYING! YOU'RE CRYING!
Side note:
Progress is going well with DNN. Pwans is part of the ecosystem of DNN, so consider that also progress for DNN. I want to see I want to show stuff by Monday at the latest, but we'll see (to basically show "oh... it works. Like in an end-user kind of works. Fuckin cool!").
There's one issue with DEG Mods that needs fixing, and it will be fixed sometime next year (hopefully early next year but I'm not sure).
It's not something any user would notice, it's just a simple kind swap to something custom, as right now, since launch, it's been using a kind standard that's definetly not fit for it. It was set that way because of, initially, a lack of proper understanding of nostr, specifically relays.
And while yes it's a simple kind swap, I don't want to break compatibility with the mods that were published so far, as well as not wanting to be attacked (spam) via a loophole because of this backward compatibility, and it'll probably take a week or so of planning/adjusting the code to finish this (with human hands for this, not AI x3).
This new custom kind will basically be the 'game mods' kind, and would be used for DEGA of course. Considering all the new custom kinds there'd be for DEGA, there'll probably be a NIP for it, similar to have theres a NIP for DNN, so I guess a... NIP-GEMS (Games E-Commerce, Management & Social).
The more time I spend planning, designing, developing on/for/with nostr, the more my brain gets rewired to think differently than with traditional systems.
It basically boils down to "think with events" like "think with portals" x3
Post-nut clarity?
Try post-noticing clarity.
Oi. Why are you noticing? Stop noticing.