Freakoverse

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).

Making: DEG Mods, DEGA, DNN, DENOS

#envtuber #podcast #gaming #gamedev #freedomtech

Public Key

npub18n4ysp43ux5c98fs6h9c57qpr4p8r3j8f6e32v0vj8egzy878aqqyzzk9r

NIP-05 Address

nabandondelivera

Profile Code

nprofile1qqsre6jgq6c7r2vzn5cdtju20qq36sn3cer5avc4x8kfru5pzrlr7sqpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0ds5wueyd

Publishing to

relay.damus.io

nos.lol

Author Public Key

npub18n4ysp43ux5c98fs6h9c57qpr4p8r3j8f6e32v0vj8egzy878aqqyzzk9r

Show more details

Last Notes

2026-03-24 19:33:19 UTC

Considering what I figured out with NSP (Nostr Silent Payments), I'm not worried about this (as in i'm not worried about an authority of some kind freezing an address, because there wouldn't be a static address through a normal payment flow through NSP).#nevent1q…6t8e

2026-03-24 11:05:36 UTC

- reply

Assuming I'm not wrong (and hopefully not x3 because this would be gold then), I've figured something out:
Nostr Deterministic Keypair Rotation
(didn't make a reference implementation yet)
Keypair rotation without a trust-me announcement, all deterministic/verifiable
https://git.nostrdev.com/freakoverse/DNN/src/branch/main/docs/NIPS/NIP-DKR.md

2026-03-24 00:41:54 UTC

- reply

https://git.nostrdev.com/freakoverse/DNN/src/branch/main/docs/NIPS/NIP-DKR.md

2026-03-23 19:37:56 UTC

- reply

The wolp's friend-in-the-head is on the side of hoomans x3
https://image.nostr.build/e979810c1b595c53167db140c042a909101ada40f16cc434cb080b1a5701f9f3.png

2026-03-23 12:58:58 UTC

- reply

Vicar Amelia

2026-03-22 18:20:01 UTC

- reply

Actually, I agree.

2026-03-22 17:54:52 UTC

I might have figured something out...!
Will write/publish something later and share it to get thoughts on it#nevent1q…40ej

2026-03-22 14:49:54 UTC

- reply

Tried it.
Whoever is making it, please continuing making/improving it, it's amazing! =3

2026-03-21 22:20:29 UTC

I'm guessing by next week i'd do public testing of the discord alt (at least web view, hoping for pc clients as well)

2026-03-20 20:47:05 UTC

- reply

My nsec is safe apparently x3
https://image.nostr.build/0e9a05fea08220b7c86519326fdb97aa115c1297aec61f4cf430628e7cfdfb46.gif

2026-03-20 19:37:37 UTC

- reply

I tried so hard for 1-3 days trying to figure out a deterministicly publicly verifiable way to rotate keys (without making a 'trust me' announcement/decleration post) without putting a parent key at risk because of child leaks, but couldn't figure out a solution x3
Now as I type this, an idea came into my head i'll juggle... but i'm assuming I won't reach an answer (but hey, won't hurt to think about it for a bit and try, who knows x3)

2026-03-20 19:33:21 UTC

- reply

Ok cool cool, my nsec didn't leak x3
https://image.nostr.build/3893ee40ae34f1a5440f333a267f29170baec1562644f8031e1899f68ad5b12d.jpg

2026-03-20 08:45:20 UTC

- reply

It's not that one has a better product, it's that it should be overwhelmingly better than whatever current product the users currently have 'and' said current product is getting enshitified at a decent pace that even its general users are getting tired/sick of it. (This is why I choose to develop the products i'm building and trying to make them a success)
While yes before when things were slow, "ooooh, new shiny thing!" was more apparent because of the rarity of options, so you'd get an initial bump of users, but general the first thing mentioned above is usually the case imo.
There's also the mentality of "i developed this fast and its good, i should market it fast and i'll be successful fast" that came as a result of how fast we're developing products now, when in reality the goal of reaching a sustainable business (aside from the development of the product part) has not sped up, in fact it has slowed down as a result of what you mentioned (basically increased competition) so you still have to go through the normal hoops and effort overtime to accomplish having a successful business out of a product.

2026-03-20 01:22:12 UTC

Alright... thought of / planned out what I think would be the best structure/flow for a discord alt, time for implementing it then testing to see if it'll turn out to be good or not.
Took me some time to realize "wait a minute, i'm not making signal and the like, a bunch are already doing that, i'm making discord, why am i trying to achieve a higher standard than I should?" and continued with that mindset / its underlying assumptions.

2026-03-17 20:12:08 UTC

- reply

neat.
would be pretty neat as well if there was a service out there that either allows users to check if their nsec has been leaked somehow, or even the service DM affected users about the leak with partial proof to alert them.

2026-03-17 10:05:27 UTC

- reply

Got my ICANN-DNS alt working, and aside from improving it and hitting up internet browser teams, I (and all who would use it) now have an option to tell my users to visit a freedom domain rather than a traditional one, if things go wrong and they take my traditional domain away, where nobody can take that domain away or ask me for any information or require permission from someone, and it's human-readable/memorable too.
https://video.nostr.build/43921e1b0338d017fdae92a11b36a2cd0a0b4755d6ad70082f79f39cc2d9b22b.mp4
It's nostr+bitcoin based (without adding anything to bitcoin).
Hit me up you're interested to learn more / happy to talk about it and/or help =3

2026-03-17 09:25:27 UTC

- reply

Realistically?
To be part of a set of relays (in partnership with other clients that do this as well) where members only can write into it and the public can read from it.

2026-03-17 00:35:00 UTC

- reply

Golf is fun again =3
https://store.steampowered.com/app/4069520/Super_Battle_Golf/
https://video.nostr.build/d9145e30ed32bf5bfdf579d5abf4222781a82aa0eebb6ea4423bc0f720555da0.mp4

2026-03-16 21:34:50 UTC

- reply

Sounds good. Applied 🤘

2026-03-16 21:28:29 UTC

Just a quickie
https://video.nostr.build/ca29b25b8c4770a3cc52300c749b7f0b984d1652096732a50209a66736dbdb82.mp4

2026-03-16 19:45:00 UTC

- reply

kind of understand it, but i don't kind of care for it x3
Let's go with "the sweat is real!" x3

2026-03-16 16:46:07 UTC

- reply

https://image.nostr.build/7d20cd58f4bd30e454151b0b4674c84820a5488a0aec25fa45048986450c87c7.jpg

2026-03-16 16:31:46 UTC

Another "free speech" platform with invite codes x3
https://image.nostr.build/6add3762849e31a0c5b71f8c9cab925565351c45d8cb6c56c1089897f0a88ea7.jpg

2026-03-16 10:00:32 UTC

- reply

What's good about new stuff is that it's varying degrees of being magical, but what I'm hoping for, that we won't repeat the same mistake again from the past, is to make the infra not-centralized, at least not completely, so that we'd start to work unbelievably hard again to decentralize it.

2026-03-15 20:49:23 UTC

- reply

1. sorry that happened
2. now i'm thinking of a comic "i'm a human rights activist, and here's a taste of the first rule of human rights *punch*, which is that you don't have rights"
3. i'm sorry x3

2026-03-15 20:44:54 UTC

i have finished Get To Work
I enjoyed playing it =3
(and i finshed-finished it, also got the hat, but not the second hat x3)
https://store.steampowered.com/app/2706170/Get_To_Work/

2026-03-15 14:11:07 UTC

- reply

Had a similar thought a few days ago.
Gist: Don't put much energy into convincing sheep/slaves to become aware/free, but rather make stuff for them to take advantage of them to benefit those who want to be aware/free, or are aware/free. This would result in an all around benefit for all (to the best that one can do. You can't 'force' someone to be aware/free, so that is the limit of what one can and should do.)
(typo at the end, meant to say: "solutions for the sheep *where we'd* utilize")
#nevent1q…ear3

2026-03-15 09:49:06 UTC

- reply

- Brought back 'username and password' on nostr, evolved.
- PC nostr signer (remote and local), lookin good, because screw makin on on mobile those are caged machines x3
- No need for any setup after keypair generation, start receiving eCash/Lightning, native bitcoin, and (soon) native other cryptos (secp256k1 based only), and no-scanning bitcoin (and other) silent payments, social native bitcoin (and other) sending, and easy multisig flow.
- encoded an npub (63 chars of gibberish) to something human-readable/memorable/usable/locally-meaningful (8-16 chars), which also acts as a TLD, and also helps solves day-0 WoT problem, relay discovery and centralization problem too, as well as no need for a CA, and more.
- Shortened event addresses (from 150-260 chars to 18-26 chars)
#nevent1q…qjdr

2026-03-14 17:21:07 UTC

DNN node code up:
https://github.com/Freakoverse/dnn-node
(check the DEPLOYMENT.md for installation on a linux server)
Here's a quick video guide to installing one on a linux server:
https://files.catbox.moe/ez977u.mp4
It's probably rough af and messy, but it's better to put something out there to play around with and improve as time goes on.
(I'd honestly want to refactoring everything from the start, but that'd waste a lot of time and not having something out there for others to check isn't a good thing imo)
You can read about the DNN project (read me and node-policy) and its NIPs (specifically NIP-DN) here:
https://git.nostrdev.com/freakoverse/DNN
Couldn't be at #soveng unfortunately for SEC-06 (Identity) and SEC-07 (Network, ICANN DNS/IANA), this project pretty much fits for both cohorts.
Identity & Signers (SEC-06):
I made a desktop signer, DENOS, that's basically the user's nostr identity manager, that's also a wallet manager (eCash, focusing on nutzap management, and native bitcoin with both native segwit and taproot for two different purposes, DNN ID/TLD acquisition & management, local signing flow and a username/password sign-in flow, and later down the line I'd add what I'm calling Nostr Silent Payments (multi-currency, Bitcoin multisig but with good/clear UX, and a merchant e-commerce POS system (that includes traditional fiat payments).
When a new user comes and generates a nostr keypair, they don't have to do anything else aside from that and you can immediatly send them eCash (nutzap focused, so no heavy token management), native bitcoin, or (later) other crypto and their tokens.
And if they grab a DNN ID, aside from turning their npub (63 chars of gibberish) into a human-readable/memorable/usable/locally-meaningful ID (8-16 chars), it would also decently add to their WoT score from day 0.
The Network Stack (SEC-07):
There's a lot here, but focused on the ICANN-DNS problem as well as the Certificate Authority problem. With DNN, you can now have https://example.nabandonaread or https://example.naboutzook , where you acquire a Top-Level Domain (TLD) by sending yourself bitcoin from your bitcoin address that was derived from your npub and publishing a few events (DENOS has this function / as easy as it can be), and after acquring a TLD, you can have many domains at no extra cost. Forever yours, no requiring payments, no auctions, no fomo, and no trading, as simple and as fast and as cost-effect as it can be, and scales well (and it doesn't add anything to Bitcoin).
SSL/TLS doesn't require CA as well, the cert would be self-signed (still secure) and you can put a thousand year validity if you want (set and forget).
It should also be prepped (i hope, didn't do much testing on this part) for a Tollgate and FIPS future.
Other:
DNN solves other problems as well, secondary-effect benefits:
- Nostr relay discovery problem (solves missing posts/messages, etc)
- Relay centralization (no need to post or read from popular relays)
- Impersonations (easily identify the correct person to follow)
- Long event addresses (shorten event post from 150-260 chars to 18-26 chars)
- Unfamiliar login flow (bringing back traditional username/password login flow, but evovled)
- More
Hit me up with any questions/feedback/topics, publically or privately, text or call (or in VRC, that would be fun y not x3) about any of this, especially if you want to implement DNN support in your nostr client (I forked Jumble and added support for it there, including some of the other benefits/NIPs like username/password login, local signer login, ID resolution, event addressing shortening, but forgot to add node query for user relay to be utilized so perhaps later), check it out: https://jdnn.top/
#nostr #DNS #ICANN

2026-03-14 14:12:39 UTC

- reply

Nice
Had a similar idea a while ago but didn't get around to implement it yet.
https://git.nostrdev.com/freakoverse/DNN/src/branch/main/docs/NIPS/NIP-NSP.md
Though working on different assumptions than what you've build.
instead of having an npub publish a SP address, no one does anything, the sender derives an bitcoin address (or any secp256k1-based crypto) from the receiver's npub and sends to him and then notifies him via a nostr event.
https://image.nostr.build/63453e6d17f65db045f752bedd5f3b079068670d11ce6e84b909564397dc8730.jpg

2026-03-14 00:44:43 UTC

Good discussion about NIP-29.
My opinion of it change from "wtf is this?" based on misunderstood assumptions, to "ok it's not that worrying".
Would I use it as it currently is? Depending on what I want to make, and with the mentality of aiming at a target audience that want to 'self-host', then maybe. Would I use an altered version of it (if you read in the discussion what that is)? More towards yes in a general sense but hard to say still for me.
For the Discord alt I'd build... there are pros in and cons for different approaches, in regards to reach that Discord quality of everything but with decentralization and censorship resistant / nostr in mind, NIP-29 or otherwise. I'll take a few days digesting everything to everything before seeing what I'd do. Leaning towards something custom but a mish-mash of things existing things... we'll see.#nevent1q…7r7j

2026-03-13 23:17:49 UTC

- reply

Aye this was a good discussion.
I'm not sure if I'll go with NIP-29 as it is or not, or go with something custom, or perhaps a meshmash of things (and present the user with "here are your options with their pros/cons"), to eventually reach discord's level of service, all the while considering the nature of nostr, is definitely a challenge, with different trade-offs depending on what's chosen.
It's definitely worth exploring different solutions i'd say, where a bunch would make products based on NIP-29 and advance it, others might build on top of a modified NIP-29, others might try something completely different, and I guess we'll see how it fares as we play with all of them and see what works best in practice.
I'll probably spend a few days thinking what I'll do on my end, digesting this discussion before moving forward.

2026-03-13 20:53:09 UTC

- reply

dumb relay, dumb client, dumb user
Chaos!
https://image.nostr.build/cb80b01b9e920f8e23ff467a36cc03516a6bd752674e9ccf17cef57090a5854d.gif

2026-03-13 20:44:51 UTC

- reply

The reason why I suggested having the pubkey in the d tag is because I'm following along with NIP-29's flow of having the relay as the enforcer/manager keypair, because without that (the pubkey in the d tag and doing a check) then a malicious user create a group a group event with the same d tag then have it everywhere, hogging relays wherever they can which prevents the normal users from having their created group be on other relays as a result of each of the other relays' keypair utilizing the same d tag by the malicious user, resulting in a centralization chocking attack (now that specific group is stuck in the relay or to a small few options, where the only solution now is to create a completely new group).
I'm basically trying to push for increasing decentralization as much as I can with the benefits of control brought in by NIP-29's management goals.
The desire to have multiple admins that are equal to each other without a creator/super-admin is more complex than having a creator/super-admin above those multiple admins, as that raises the question of who should the relays listen to when there's a dispute? We'd either end up having chaotic battles of constant back and forth changes, or there needs to be a voting system for consensus, and the other issue is if one admin wants to kick another admin, is that respected? what system should handle this?
I hope I managed to explain well what the issues of not having a creator/super-admin that relays listen to as the final authority. It's not that there can't be equal admins, but that there must be a super admin (creator) above them to not have such complexities and potentials issues.
If there's a desire to fork the group, then that can be done by just mentioning the original group id (d tag) under a new tag, when the new creator publishes their group, and the relay grabs the relavent events.

2026-03-13 19:55:04 UTC

- reply

If I had to gist each...
One piece villians (at least those) (if i'm thinking right):
"I'm just evil" (regardless of backstory, those chose to be dicks x3)
Bleach (again, if i'm thinking right):
"fuck those in power"(aside from Ulquiorra? he's his own thing x3)
Naruto:
"i suffered in the past, so i'll end the worlds' suffering by force" (aside from Orochimaru, he wants to break life's limits and hungry for power, trying to achieve them by any means necessary)

2026-03-13 17:22:19 UTC

- reply

So it seems like things could work with NIP-29 for me (and others?) to build on it, but a bit of changes would be needed in my opinion:
I don't see how it's good not to have a link to the practical (actual) creator of a group.
The relay can remain an 'action' authority, but the creator needs to act as the higher/'actual' authority as a link of sorts. Meaning I'd publish the creation event (mandetory, not optional, and if privacy is a concern then a deterministic derivation from the creator's pubkey can be used) and whatever i change with the rules, or who is allowed to change the rules (admins, moderators) is published by me, and the relay enforces them.
This gives a proper view of who controls what, and it would be visible if a relay misbehaves / becomes malicious (if the relay changes the rules and does other enforcements that they creator did not publish, then it reveals for everyone that the relay is misbehaving / is malicious).
Regarding the d tag, it shouldn't be <host>'<group-id> but rather <creator-pubkey>'<group-id> where relays must not create a group without seeing a creation event with that same d tag published by the same author as <creator-pubkey>, this prevents a malicious user(s) from preventing a creator from migrating their group from one relay to another because of d tag colision. The cost of doing this, however, is that it would not allow the functionality of forking a group, but that can easily happen fixed by adding a tag to tell relays "this is a forked group, so grab grab posts with this d tag as well".
With that in mind, the h tag would also have to have the <creator-pubkey>'<group-id> value.
Considering the removal of <host> from the d-tag, we'd utilize the order of the r tag to identify the current relay authority, if that even matters, where we can just have multiple authorities ("enforced") considering that we'd now have the 'actual' authority being the creator.
That [private] part is a protection from the general public, but not from the relays, so the solution here is tree encryption / mls-ish (optional).
No new kinds, just tweaking the flows and assumptions.
This gives power to the user/creator, while complexity and processing remains with relays and enforcement remains on the relay side as well, and there wouldn't need to be a 'migration' because of this anymore, you'd just add/remove relays from the creation event and rebroadcast events.
To me this seems like the best of both worlds, but perhaps i'm not seeing something or have misunderstood aspects of it. Thoughts @npub107j…ncxg @npub180c…h6w6 @npub149p…722q ?

2026-03-13 12:55:07 UTC

- reply

Took a bit of time to understand what you said in the quoted post, and I think I understand now where you're comming from regarding the design of NIP-29, where the best management and moderation flows happen on a centralized system, but when other protocols tried to do that but in a decentralized manner, they still end up with the flaws of centralization, but because of nostr's unique structure, it allows the possibility of migration from the original relay to another, in case it shuts down or starts censoring the group. Most other protocols (or all?) can't easily do this in comparison.
I understand the logic of where you're coming from now, and I'm not against it, however... I guess I would be more of a fan of NIP-29 if there was a good flow for migration steps, and more so if there was less dependancy on one relay (so a group would post on 2-5 relays that enforce admin policies) and decoupling the relay address from the group address. I think at that point I'd be happy to use NIP-29.
(and in regards to actual privacy, so not even the relay knows about the content of the group posts, we'd have that tree-based encryption, so i guess no worries there, it wouldn't be that high of a cost even at scale)
Also, yes you're correct that what I thought of (or what Niel linked to) has high processing, where the bigger the group the bigger the procesing needs to be done on the client side and that is definitely an issue. I guess that's the cost of if we want to persue the core nostr flow that has been done for most NIPs and what most people love about it.
(Moderation management with shared pseudo-powers can be done here, but yea, more client-side processing as a result, and full final actual moderation is done by the creator of the group)
I'll explore and think about NIP-29, to understand it more properly but to also see how can it be adjust to improve the hiccups i see in it (addressing the part where i said "I would be more of a fan of NIP-29" in this same post). Basically lossening up NIP-29 a bit more (probably not the correct wording here but i'm hoping I'm understood) would probably make those that don't like it reverse their thoughts on it and embrace it.

2026-03-13 11:19:30 UTC

- reply

Based on my understanding of NIP-29, one thing I didn't like about it is if the relay goes then the created hub goes with it. If the relay doesn't like the hub I created, then they'd just block it and then i have to create the same hub again on a differen't relay as the new home. I'm relay hoping my hub now basically.
Unless I misunderstood how NIP-29, that's how I'm seeing it at the moment.
In regards to how I'm planning to build that Discord alt differently, when you make a hub, it's an event with relay hints inside it (multiples), and posts reference the hub ID and push posts to those hint relays. For moderation, it'd be based on whitelists and/or blacklists, or rather depending on the hub structure then basically a 'access control' list (in regards to encryption / what can be seen, tree-like access tokens / similar to how MLS works if i remember right), basically client side showing/hiding based on access control list, and encryption/decryption based on who's in the tree and then token always gets updated everytime the tree gets updated and participants would know/get informed of the token.
I hope I explained things well, sorry if I didn't.

2026-03-13 11:08:34 UTC

I figured out how to word my dislike of most turn-based games:
Aside from being generally boring to play, there is barely any or no skill involved to the gameplay (keep in mind i said "most turn-based games").
Persona, for example, you can't do decent damage? You're dead.
Elden Ring, even if you're naked with one HP and the beginner sword, you can finish the game if you're skilled and patient enough.
An example of turn-based games where good skill is involved (unless you're a robot?) where it's not just bigger number = better, that'd be Chess.
Another example, though i haven't played it yet, that leans away from no-skill-turn-based, seems like it'd be Expedition 33.
#gaming

2026-03-13 11:00:22 UTC

Seems like there's discourse with NIP-29 again?
Yea it's still bad, at least in the sense of building a product for the general public.
I think I don't like it because it makes me thing of ActivityPub/Mastodon (it's not it, but it's decently leaning towards it).
The Discord alt I'll be building won't follow this NIP at all.#nevent1q…c0fm

2026-03-13 10:51:46 UTC

Had a quick discussion with a friend that recently got into #nostr and provided me with their experience, where he didn't mind the technical hiccups, the shit UX here and there, what he really minded was not finding people to follow that were sharing things he can relate to, where a lot of what he found were people mostly talking about nostr and bitcoin.
Basically the same feedback all nostr devs get most of the time.
However, the solution most devs get wrong is not, imo, the correct one, where they've made lists of various topics to follow specific people, different types of algos, etc.
The solution I told him (and the public whoever is reading this now) are a few things:
- Wait and see when companies you're interested in to say "follow us on nostr", where you'd then follow them, see their post, interact with them and interact with others that reply in their posts, and check with those people that are replying to see if they post stuff that interest you and follow them if it passes your interest threshold.
- Use nostr products that are of specific industries or topics, where you'd specifically see posts about those industries or topics.
- Lastly, use hashtags of things you might be interested in, in terms of search and posting as well (someone might follow you as a result of searching for that hashtag and you'd follow them back if it passes your interest threshold), where you'd search for posts with those hashtags and see who to follow based on their posts.
That's how I've been using social media all my life to fill up my follow list enough that it keeps me entertained/satisfied with my feed experience, I did not rely on lists or algorythms at all (as i didn't see a need, not that i was against it, so it was useless to me).
Regarding that second point, to expand on it with examples:
Primal, Damus, Amythest, Jumble, or even DNN or DENOS that I made, etc, are products that don't bring in culture, they are just general tools or systems.
DEG Mods and soon DEGA (game mods and games, games industry) and other things i'd build, as well as others (one that I know is about drinking wine / communities around that. Another is about anime/manga, etc), are cultural products that bring in specific types of people that share the same interests together.
Because of the nature of nostr, cultural nostr products will be the driving force of filling the void of 'people to follow', along with the other two points i mentioned, that tool/system nostr products are missing.
Building tool/system type products are very important for nostr, but building cultural type products are very important for nostr as well. If you're a dev, build what you want, but keep in mind the difference.

2026-03-11 07:19:55 UTC

- reply

It's a result of a new protocol being built, based on nostr and bitcoin.
Basically: from you npub a bitcoin address is derived, then you send yourself money (btc) from it, publish a few events (can be 1 click), and now you have a unique TLD where you can have many domains with at no extra cost forever.

2026-03-11 00:29:49 UTC

- reply

Would this work?
https://image.nostr.build/71e32f5cbe1572eee73e1383c31b2af7183f1d158952a41e79b558737b934977.jpg
https://image.nostr.build/a60f3933ac360c5e2dd2cac64d2f01c9be508ef44e8c29fab951a9c48b05cb15.jpg
https://image.nostr.build/ccabe2277673ceef03c8e2924b1831375836c420a8d8479fb1f051a411cf413f.jpg
https://image.nostr.build/7176ec1bf5ddb97fa438fe90ce99ba03db2b91c53843027d57fed92ec3634784.jpg

2026-03-10 21:52:29 UTC

- reply

Being threatened via namecheap as well but for a different matter (A government is threatening me to take down a post).
Will change registrars soon probably, something in Asia most likely.
Hopefully I manage to get things rolling with my ICANN-DNS solution so that no one needs to worry about these kinds issues ever again =3
nostree.nareazook could be the potential future domain for example =)

2026-03-10 17:31:27 UTC

- reply

As far as I'm concerned, in regards to not seeing reactions / replies almost fully, this is mostly solved through the solution I've made (the cost: an actual cost of a self-transfer on bitcoin), that's a secondary solution to the main problem it solved.
The issue:
You make a post on one relay, some people may reply on a different relay (assuming they even saw the post in the first place).
The wrong solution (that's currently happening):
People follow and post on popular relays. In other words: Relay centralization.
My solution (which is a solution to the ICANN-DNS problem but happens to solves many other problems as well):
You can find someone easily, find their relays that they use and would always be update to date so you don't do anything, so you'd see their posts, and when you reply/react/anything > it sends that info to the relays the post is at. This solves relay events discovery, and as a result resists against relay centralization.
Previously it was thought that this issue can't be fixed, turns out it can but at that cost of an initial bitcoin spending.
I can remove that initial bitcoin spending cost, but the tradeoff is having no control so this isn't desired.

2026-03-10 00:43:26 UTC

- reply

https://image.nostr.build/9d4bb63bec56c2ac4947c71634c8c5efa2038070cc4b78543ef193325156a5fc.jpg

2026-03-10 00:41:00 UTC

- reply

(Mentioned this because there was also a window of time where his domain was down as well, and there are multiple examples of people having their domain taken away)
Regarding patreon, not sure when, but it's already prepped in the nostr desktop signer that i made, where it'll enable decentralized traditional fiat payments to nostr users/creators.
Aside from that, regarding video hosts, Blossom is a thing but in terms of achieving good decentralization of large files (media or otherwise) an economic infrastructure needs to be built (and at least for me, i want to build this as well, but considering the complexity of how i want to build it, basically an evolved ads-system that's beneficial for all, it'll be a while until i get to it).

2026-03-10 00:32:16 UTC

- reply

Yes, I made it / figured it out, and releasing the probably horrible code for it soon, here's a demo:
https://video.nostr.build/a2cc23b88527ba5b445ceea7a058a1dfda50679426a644e974e3e748be7cc03a.mp4
And yes, that short domain example, example.nabandonaread is a censorship-resistant permissionless bitcoin-anchored nostr based domain (without adding any junk/spam to bitcoin), that's as cheap as it can be, as relatively fast as it can be, as easy as it can be (send to yourself money, then publish/edit your domain records), and extremely scaleable (you're getting a TLD, so you can have as many domains as you want with zero cost), and self-signed certificate (no need to rely on the Certificate Authority), all the while resulting in secondary-benefits (fixes the relay discovery and centralization issue, enables traditional but evolved username/passwords login method, resulted in the creation of shortenting nostr event/post addresses, and many more).

2026-03-09 01:26:59 UTC

- reply

This is great / seems like the best discord alt out there at a glance =3
Though yea there's the issue, 'self host', meaning you could still get banned / account wiped and censored by the self-hoster, and you'd have to register a new account each time you'd want to join another self-hosted instance, and if someone wants to properly have their own server then they have to go through the hassle of getting and settup up the server and convince their friends to make accounts here along with the other times they've done it.
So yea, as you said, that nostr-based is the goal that doesn't have any of these issues =3
Well, no issues in regards to text, the only issue is voice/cam/stream, which is at the moment something that must be self-hosted, but already have a solution for that in mind, however, it's part of a much larger project so it'll be a while until I'd get to it.

2026-03-09 01:20:22 UTC

- reply

Here's how that's solved through my own experience on traditional media:
1. I see companies advertise themselves 'follow us on TwiX', then i do, and i see their posts, i see people reply, i engage with the post and replies, i check people out, if i find them interesting from what they've posted in the past I'd follow them.
Basically the solution here is is a company/studio/product/influencer/whatever-of-value is announcing that they're posting on XYZ and people would follow.
2. People post with hashtags, i search for those hashtags, engage with posts there, and same process with checking profiles out and following
3. Forums (reddit, etc), i check posts on categories/subs that i might find interest in (gaming, anime, etc), and see what peoples my interest, and engage, and i repeat the processes from the above two points.
This cycle repeats for whatever platform you'd be on. You'd get a lot of people to follow and engage with now.
4. The new kid on the block regarding these flow: Algos.
Tell it what you like, hopefully it shows you stuff you may like, keeps monitoring your activity and adjusts itself to fine-tune what you may like and hopefully follow/engage with people.

2026-03-09 01:11:25 UTC

I decoupled the names event from the connection records (like dns records for when you update your domain) in DNN so you don't have to update two places at the same time (not sure why I decided that in the past...).
DNN node peer discovery is working (two nodes on two different hosts), but there's a design flaw with it that I'm fixing.
After that, I need to make sure that the DNN daemon is working after that decoupling change, along with the forked Min browser, double-check on delegation if it still works along with ssl/tls self signatures, clean up docs, then I'd release the DNN node code (so that people can see the horror, but it's working! x3).
I want to also see if I can package it for umbrel/start9/cloudron, but I'll pause that for temporarily.
Then I can start poking nostr clients on their thoughts about it, and see if they'd implement it into their clients, then start talking with browser projects/devs for the same purpose, then linux distros, etc.
During which, I'd start working on that Discord alt.

2026-03-09 00:56:00 UTC

- reply

I've tackled this issue with my ICANN-DNS solution (funnily enough) that came as a secondary-effect benefit.
It's not 'the' solution, but 'a' solution, one that provides a permanent static short address that's human readable/memorable, that has behind it relay information that can be changed without changing the user address/ID string, which also solves the relay centralization issue.
The cost for all these benefits? For the user to do a one-time initial process of: a Bitcoin self-transfer from their Bitcoin address that was derived from their npub address then to publishing 4 events (one click tho).
End result example:
npub 18n4ysp43ux5c98fs6h9c57qpr4p8r3j8f6e32v0vj8egzy878aqqyzzk9r
to
nAbandonAreaD
(not case sensative. censorship-resistant, permissionless, etc, + have those relays behind it / the benefits i mentioned (plus a lot more benefits) )

2026-03-08 14:37:06 UTC

- reply

For me I was already planning to do this for my game mod platform and the eventual game store/client, so this would definitely help (in the eyes of a company trying to provide a service, but also a step in the future for...), and also to expand the decentralization of those who hold such large files to offer them as a service, there needs to be a an economic infrastructure of varied options to facilitate its growth, in a direct action (pay to download/upload) or automatic (free/watch ads), for a seemless high-quality download/upload experience of large files (it'll be a while until I build that economic infra tho).
Torrenting would of course still be an option / fallback.

2026-03-08 14:25:50 UTC

- reply

We're getting chunks/chunking to Blossom? Nice =3

2026-03-08 14:20:08 UTC

- reply

Still not it's final form, but if you want check out (fork?) what I made (desktop signer / bunker + two other login/signing methods + a lot more)#nevent1q…u6nv

2026-03-08 01:07:38 UTC

Hopefully I'll remember to add DMs to the forked version of Jumble the way I see it UX wise + with the more private nip17 version of it / zero metadata leaked (that also stops potential spam from being received and processed, but at the cost of not allowing people to cold DM u) I figured out for a client.

2026-03-08 00:04:47 UTC

- reply

Another perspective to add on to this:
If other clients don't want to respect expiration tag, it'd be beneficial for the user to see a tag somewhere, something like "Expired", and tapping it would lead to show more information about the post that was original set to expire on date/time xyz.

2026-03-07 23:59:17 UTC

- reply

you can hit me up here, it's not like there are hundreds of people reporting issues yet x3

2026-03-06 22:40:57 UTC

- reply

I really want onion rings now... it's been a while.

2026-03-06 18:39:11 UTC

Funnily enough, this made me realize how amazing DNN is, not DNN itself but the idea behind it: Cleanly, harmlessly, and effeciently anchoring nostr identity to Bitcoin that results in unlimited application/usecase possibilities.
At first I was amazed "holy shit is the ICANN-DNS problem solved?", and in the past two days I've realized "holy mega-shit this extends beyond solving ICANN-DNS". DNN is just the first application/usecase/solution in this system.
This also means, to a degree, there's no need for a lot of alt blockchains to exist, so this isn't a threat to Bitcoin, this is actually a potential threat to a large number of alt blockchains...
But I'll only be focusing on DNN for now and make that the best that it can be and try my best to have high adoption with it so that people don't need to worry about ICANN-DNS (and SSL/TLS) anymore. Others could figure out other services with this now discovered system, which... let's call it 'Cross-Protocol Anchoring'.
A process that connects a key from an identity protocol (e.g., a npub in Nostr) to a key in an anchor protocol (e.g., a Bitcoin address) to produce a verifiable connection record within the anchor protocol. This connection record can then be used as a deterministic reference point to tie application-specific data under the identity protocol, without modifying the anchor protocol itself or adding any new data to it.
This probably needs a document or whitepaper or something to be written for it. Hopefully I'll remember and find the time to do that x3#nevent1q…8hmj

2026-03-06 12:46:48 UTC

- reply

If the people don't resist (actual resistance to force a correction towards freedom, not #omgfreedomtuesdays x3), then they will be slaves, that's about it.
But, with the assumption of a future where the majority are sheep and salves, then there'd simply be two worlds:
The world of masters and salves
The world of free people passing through those masters and slaves
However, with the assumption of a future where people resist but are still sheep-ish, then the mater of having a free world will depend on creators making products that are so good that the sheep go out of their way to want to use it, and these products would have freedom infrastructure in the background (invisible freedom for the sheep) for the benefit of the sheep but more importantly for the benfit of free people.
That's also the issue with a lot of freedom creators btw, they try hard to convince the sheeps/slaves to be free, when they should focus on those who want to be free instead and provide them with the highest effort possible, which includes (and this strategic part is forgotten) making solutions for the sheep to utilize/take-advantage-of them, not directly help them, to benefit the free people, which may sound horrible, but then you'd notice "the moment a sheep/slave decided to be free, then they're in the beneficial side already".

2026-03-06 12:28:23 UTC

- reply

"certain scenes"
x3

2026-03-06 09:52:22 UTC

btw, i haven't mentioned this before, but DNN isn't reliant on DNN nodes to work (and that's pretty cool!), but it does rely on it to lessen the load on users/nostr-clients/browsers/OSs, as well as provide a similar quality of service and reliability of traditional DNS and services like Mullvad/Cloudflare for content moderation and saftey.
Having a DNN node network/system also provides many other benefits, aside from reliability, so that's another reason for its existance and value for people to run one up.
If you're wondering how it isn't reliant on a node to work:
naboutgateb > translates to block 6744 at position 2 > queries bitcoin nodes to find the specific transactions ID after applying rules > queries multiple nostr relays to find an event published with this TXID > finds it then the npub that published it to derive a bitcoin address from it > if the derived address matches the input/out of the bitcoin transaction then it's verified that this npub is the owner > print: ☑ for ID verification /or/ start fetching domain records /or/ start fetching metadata
This all would be done client-side/browser-side/OS-side without a DNN node, unreliabily, but with a node it handles all of the middle part and highly reliable.

2026-03-06 09:25:56 UTC

- reply

Ye, and I don't think what I made would kill Bitcoin (if it did, that'd be both awesome and horrifying at the same time x3), as it's just a clean normal transaction.
I think the issue that they thought of is not DNN itself, but the discovery it made, where people can utilize bitcoin for other usercases, any usecase actually, without adding anything to bitcoin / a clean transaction, and this discovery may result in the creation of other usecases (ex: pay to self/other to prove you're human, pay to self/other to progress in a game, pay to self/other to get xyz value) which could potentially take up decent space within a bitcoin block, and those other usecases would share said space with the initial usecase of sending money from A to B (one person to another unique person), resulting in increased fees for all use-cases and the annoyance is that would include the initial usecase as well (sending money from A to B / human to other human).
So basically, because of this discovery, as time moves on, the fees will only increase from now on because of how pure this discovery is and can't be stopped.
Assuming I agree with this fear, as mentioned, the discovery has been made, pandora's box has been opened and cannot be closed (attempting to close it is attempting to destroy Bitcoin, as this isn't something one can stop like fixing op_return or Ordinals by removing them, where the 'solution' to fix this 'problem' is the introduction of authoritarianism/centralization), as such, requesting me to stop doing DNN is unfortunately not the solution, as another would take my place, and more would make more usecases, and this can't be stopped.
The actual solution is already set in place, market dynamics will dictate the fee rate and will kickout other use-cases that aren't valuble enough to make a transaction more than X value (1 sat, 2 sat, etc) and people who want to make a traditional transaction (send A to B) would now not have the smallest possible fee for a transaction to be complete at a reasonable time. That's the downside of this whole thing as it grows, instead of people 1 to 5 sats per v/byte fee rate, down the line it might be 1 to 20 for example.

2026-03-05 15:23:44 UTC

Had an interesting discussion with another person about bloat/spam on bitcoin, we were pretty much on the same page, aside from my DNS solution with DNN.
Even though DNN doesn't add anything to Bitcoin (no op_return data, no exploitation of witness data / taproot, zero), no writes, where it only reads from Bitcoin as users do a simple self-transfer (bitcoin address A sends to the send bitcoin address A), I could not comprehend the presented issue of:
'There's now an incentive for people to do self transfers, and at scale this would result in bloat in bitcoin not for its intended purpose of sending money from A to B.' (paraphrasing)
I couldn't comprehend the presented or perceived issue because:
1. It is sending A to B ('B' being 'A' itself)
2. It doesn't add anything, no bloat
3. Even if a full block or blocks were about these self-transfers, they are legit and clean (no non-transactional data / zero)
The gentleman I was discussing it with see DNN as a bigger threat than Ordinals, which came to me as a surprise considering I myself am against it, and don't mind also if op_return was zero, and that's why I made the DNN the way it is now.
My best attempt at coming to an understanding is that because the reason/incentive isn't about sending money from A to B just so that B can have the money, then this shouldn't be socially pushed to become mainstream because if it catches on and many people start doing self-transfers, it'll bloat bitcoin blocks with these self-transfer type of transactions. But even then, my thought was "So... because the reason/incentive for sending a transaction isn't for sending someone money or utxo consolidation, then it's a bad utxo, even though it's no different from any other clean utxo, if not cleaner in comparison to many other utxo because no op_return rule + input=output, as in as legit/greenlight of a bitcoin transaction as it can be".
I was wished upon that I'd stop doing DNN because of this perceived threat that's supposedly bigger than ordinals and op_return (combined?), but wtihout coming to understanding how this is that big of a threat, if a threat at all, I probably won't...
...not out of being malicious, as I'm simply solving the ID and DNS problem with it, as effeciently as possible, and as cost-effective and cleanly cleanly as possible, and the most simplest with the highest security possible, and there's no one backing me, and I won't be getting anything out of this aside from using it like everyone else, so there's no conflict of interest or ulterior motive (not saying anyone is saying that, just trying to deliver a point, which is...), so since I can't see or understand the problem, then I can't even agree or disagree if it is a problem or not to then decide if i'd continue making DNN or not, as a result i'd continue making it.
From my point of view after thinking about it, the pushback isn't a protocol purity resistance (resistance against op_return/junk, witness exploitation, etc, which is a legit pushback and I resist it as well), but rather a hyper purestic ideological that extends/overeaches outside of bitcoin.
Going back to what Satoshi mentioned about this topic, where one or more people asked about adding a DNS solution into Bitcoin, the idea was rejected and suggested that a DNS solution should be on a different chain, so that no non-bitcoin/transactional data is added to Bitcoin, and as a result namecoin and others like it were born, however, the discovery with DNN is that it follows that exact logical reasoning: nothing is added to Bitcoin (no spam/junk/bloat), and DNN only observse it (observes only clean transactions).
If there was such a thing like a 'Satoshi Test', then DNN passes it with flying colors.
When I think about my opinions on Bitcoin in regards to what should be done with it or what shouldn't be done with it, the line is clear: don't add unrelated things to it (op_return, witness exploit, ordinals, etc), don't overreach (prevent people from doing a normal utxo because of a disagreement on the why, which is more dangerous as that would add subjectivity to objective system).
However, I might have gotten something wrong or am fully delusional, so if you have thoughts, feel free to share it.

2026-03-05 00:24:17 UTC

- reply

Pretty much me as well, more so on the fictional characters x3
https://image.nostr.build/4ffc86c3e6db0ea02860bc4572ca1e13f07af2c66f2166640a7edb69a2407f8c.gif
About that, many people unfortunately think it's sad that someone admires a fictional character, as they don't realize it's not the character itself, but the traits, the qualities, the ideas of the character, not the character as a person.
Even with real people, mostly what's in my head goes "I love/like/etc this idea" not "I love/like/etc this person (that thought of the idea)"

2026-03-04 21:05:29 UTC

- reply

Depends, can i claim tax deductions? x3

2026-03-04 20:55:25 UTC

The people you like and/or respect and/or admire might make wrong decisions, have bad opinons or stances, or even do something bad, and it doesn't mean that you have to agree with them, follow what they have done, or defend them, and it's not wrong to point it out, and it also doesn't mean that you have to cut them off or stop liking/respecting/admiring them.
Focus on the topic, do what you think is right with it, unaffected by the people around the topic, be it friends/family/etc and how it may affect them, and carry on.
Reitirating, be it friend or foe, god or the devil, take what's useful to from all to help you reach what you'd think is right and cast away all other elements unrelated to the topic (the idea, the problem, the solution, etc).

2026-03-04 14:33:02 UTC

- reply

Will you do the introduction like:
"In a world..."
? x3

2026-03-03 13:08:02 UTC

- reply

ur poster makes me think of linkin park for some reason x3

2026-03-03 13:07:01 UTC

- reply

Wishlist:
-Toggle to auto-replace for the selected client (dangerous) + keep signing policy
-FAQ subpage in the settings page, and specifically to add a guide on how to delete a pin account if you forgot the pin (dangerous).
-See if I can package this so it can be ran on umbrel, start9, cloudron. For more permanence for general use + important for the merchant flow when it gets added.
To do:
-Fix flatpak

2026-03-03 00:58:42 UTC

DENOS
A PC nostr signer, DNN ID manager, payment system
https://cdn.satellite.earth/bfb0a576daad9e172c93f21320a73f7142ec1c577cd6eb043c9fc5e18ffbabe2.mp4
- Available for Linux, Windows, Apple (Annoying to use on Mac because I won't have an apple dev account anytime soon. Tested Linux deb/pkg(friend)/appimage but not rpm or flatpak)
- Generate a 24 word seed and get nostr keypairs (or import 24 words / nsec)
- Three flows to login (bunker (nip-46), username/password (custom nip-upv2, local (custom nip-pc55))
- Different options to handle signings for each event and clients (approve/reject, auto approve/reject kind, auto approve/reject everything from client)
- On signing into the same client without cached history of the previous login, asks if you want to replace the previous connection (with saved policies toggle) or create a new one (or cancel)
- For the username/password flow, it would detect if someone that knows your password has attempted to login with it while the signer is offline (might be you / false alarm, but you'd be notified regardless)
- Bitcoin wallet derived from your npub (so not from your seed / no expectation of HD style wallet)
- eCash (nutzap specifically is what's mainly used, tokens encrypted to receiver's npub, that's how i see ecash on nostr, always)
Here's the source code (Download for your OS in the releases page. For Windows use the .msi installer):
https://github.com/Freakoverse/DENOS
And if you want to test out the two other login flows (username/password and local/nip55-butOnPC), you can use:
https://jdnn.top/
Future:
- Nostr Silent Payments (custom nip-nsp)
- Be able to receive more than just bitcoin natively (Any secp256k1 can be supported)
- Bitcoin multisig (based on seed, not npub) with nostr comms flow to make this shit easier x3
- Point-of-Sale system for merchants to do e-commerce with traditional payment methods over nostr (custom nip-dpos, for the DEGA project / any e-commorce project)

2026-03-02 09:11:14 UTC

The comeback nobody expected
https://motorolanews.com/motorola-three-new-b2b-solutions-at-mwc-2026/

2026-03-01 20:05:18 UTC

- reply

Agree. I got that with Bathesda games when i gave one or two of them low scores (and by low i mean people freak out if you give them anything below a 9 or 8), and people see some of the critisms and reply to me "it's always been buggy", and in my head "okay? then it'll always have that critism and lower score x3"
(and it seems like i didn't deliver my joke correctly x3)

2026-03-01 19:42:28 UTC

- reply

But what about other big plagues?
x3

2026-02-28 23:48:22 UTC

Also been enjoying Super Battle Golf with others, good game and cheap =3
https://store.steampowered.com/app/4069520/Super_Battle_Golf/

2026-02-28 23:46:06 UTC

Enjoyed the demo for Windrose =3
Hope they make a zoomed-out mode while controlling the ship.
Would be nice if non-ship combat could be improved.
https://store.steampowered.com/app/4291770/Windrose_Demo/

2026-02-28 23:43:48 UTC

New Gorillaz music video dropped =3
https://www.youtube.com/watch?v=ucRulNQsuYQ

2026-02-28 14:32:16 UTC

- reply

Had a discussion about this with a friend that recently got into linux (using arch, btw. x3), goes to use 'sudo pacman -S package_name' to install stuff, and after asking him a few question about 'pacman' and 'yay', my understanding/conclusion that it was permissioned basically, to have a package distributed through them.
I thought 'well nostr/dnn can solve this' where i'd imagine after some dev and setup, we can have something like 'sudo dnn_user_id -S package_name' (ex: sudo nabandonaread -S zapstore' where anyone can easily make a list for themselves or their friends, or a dev/studio/company making their own list and distributing whatever they want. That's for the terminal, and in a gui sense, slap in dnn ids (npubs) in the settings of the software manager and they'd appear, or rather, if you 'login' with your nostr, you'd see all of your following's lists.
So basically zapstore user app lists with dnn id (optional) for linux packages x3

2026-02-27 23:26:05 UTC

- reply

ye
either way, because of nostr, i don't have the power to properly remove it, so let's see if they can find the main poster and see if they'd remove it if they want to (and even then, relays might not respect the wishes of the original poster and always blast a copy of the mod post event, so not even the creator could have power to 100% for sure have removed the post).

2026-02-27 22:25:30 UTC

- reply

I don't think that'll look good on my resume x3
Aside from that, is the mod horrible? Absolutely, but it doesn't seem to dox anyone, so there's no actual issue, but that's besides the point, where the point being is your domains can be rugged from you without your permission.
Glade I've been working on DNN =3

2026-02-27 18:35:43 UTC

- reply

"I like banana yo"
>run it through an offline AI that transforms what you say into a standard way of speaking where everyone using it would have the same pattern
result:
"I possess, sir, an affection for the banana so profound and unwavering that I daresay no finer fruit has ever graced the table of civilized man; indeed, my esteem for it is of such magnitude that I proclaim, with the utmost conviction, that I am most exceedingly and ardently fond of the noble banana."

2026-02-27 16:38:18 UTC

Perhaps I can demo (and release) something new tomorrow (hopefully)

2026-02-27 15:52:38 UTC

- reply

A short demo reminder of what can be achieved with DNN
https://video.nostr.build/a2cc23b88527ba5b445ceea7a058a1dfda50679426a644e974e3e748be7cc03a.mp4

2026-02-27 15:38:15 UTC

The New Zealand government sent DEG Mods a takedown request of a game mod post through Namecheap, with a threat of legal proceedings of sorts, which may result in Namecheap suspending access to the DEG Mods domain address.
Good thing DEG Mods was built on the awesomeness of nostr, and good thing that something like DNN was figured out developed, and with a good push to have browser parterships, there wouldn't worries about having your domains be unjustly shut down anymore or stolen from you
https://image.nostr.build/1a781096aa235f64298d1c3528efacdf1740c84d751cd88b284688c9e7229aa6.jpg
https://image.nostr.build/8f96bb4328e762ce6d40d88a4a60d9819a40b18b6964c5d9de73d831fb8690f1.jpg

2026-02-27 09:15:24 UTC

- reply

So something like this?
Ya i can get behind this, an all purpose for service discovery + information about economic model
https://image.nostr.build/46bd1aff565161dbd1569b9fd440bd9dfac63024ac6596fed94d4fb1805a9354.jpg

2026-02-26 23:09:39 UTC

- reply

quickly yes, just to get a few of them for testing stuff.
but if i want to be effective about it, i'll most likely make script that does all that stuff for me for however many it can get and organize them in a list.

2026-02-26 22:24:41 UTC

- reply

it was a pain to swift through since there are a lot of duplicates
an announcement would make things so much more easier to discover them

2026-02-26 22:23:25 UTC

- reply

that's the centralized source i was talking about x3
(or is it not? didn't check how it lists them)

2026-02-26 22:12:20 UTC

Why isn't there a nip/kind on nostr where the purpose is to announce a blossom server "hey, i'm a nostr server"?
I'm manually trying to find servers through user server lists and checking a list on a centralized site =/

2026-02-26 18:18:15 UTC

- reply

Heya, sure thing, if you'd like, we could have a voice call. I'd imagine it'd be more effective that way.

2026-02-24 09:01:50 UTC

- reply

Yes I had a similar idea along time ago / a bit after i join nostr, but what i was trying to achieve the past week was, from the looks of it, was an impossibility (until i or someone else figures out a workaround solution somehow).
What can be done:
Parent npub > hardened(child-0)
Parent npub says to the world 'I authorize this random npub to represent me'
The parent knows that the child actually came (derived) from them, but because it is hardened, the public can never confirm this, as such, to the public, they view this as a 'random npub'.
Can the public verify that a child came from a parent? Yes, if the child isn't hardened, however, as a result, if the child private key leaks, then the parent private key also leaks, defeating point of this whole thing.
The problem that I couldn't solve:
Can the public verify that a child came from a parent, without risking the parent private key?
Unfortunately the answer after trying was: no.
I've hit the wall same as everyone else and couldn't figure out a workaround.

2026-02-24 00:43:07 UTC

- reply

EH?! xD

2026-02-23 22:03:56 UTC

- reply

well, that would be nice x3
but this is related to a specific part of it, an interpretation of a part of it.
foreshadowing or something, not sure x3

2026-02-23 21:43:09 UTC

Side note:
This clip is a representation of an important design decision for DEGA
https://video.nostr.build/a05468b4ec7f3996fba8abee7e3447c28ff8634ea28fafcf1b7eae7066607b88.mp4

2026-02-23 20:36:05 UTC

- reply

But... damn.
x3

2026-02-23 19:16:04 UTC

- reply

https://image.nostr.build/a4fa8e6989e5b6ebcbf72f2c5b81410c9cdd90c055c002a6a2f3ec3a19980fa7.gif

2026-02-22 23:36:41 UTC

- reply

Time to admit defeat on this.
I think I spent 24 hours trying to make it work with my standard that I want, but nope. I've been hitting the same wall everyone else has and can't break/pass it.
Maybe one day i could, but not today sadly. Archiving this (in my head) and moving on.

2026-02-22 11:23:16 UTC

People who want 'versus player' in a pve game, where the reasonable can see the frustration of those who don't want it.
People who don't want 'versus player' in a pve game, where the reasonable can see the dynamic intenseness of those who do want it.
This is a problem cause by developers not being able to figure out an enemy type (or types) that would not result in a need for a 'versus player' in a pve game.
The moment someone figures out such an enemy type (or types, or rather, system), where even if you notice the patern of it, it's still as engaging as facing another player, is the moment this problem is solved and the game that implements it would make it big.

2026-02-22 08:56:41 UTC

If Stalin, or someone that works for him, said "drinking water for when your body needs it is good for your health", does that mean it's wrong?
If God, or one of the angels, said "stealing houses is a good thing", does that mean it's right?
It seems like a lot of people think think about the person to cast judgement on the topic.
Think for yourself about the topic, not about the person. The seperation of topics and people lead to a good a healthier result.
That's my comment for the silliness that's happening right now.