moegrammer

I try to build things

Last Notes

2025-08-10 03:21:52 UTC

- reply

Awesome to see that you've continued to chip away here @nprofile…7gha . Great stuff

2025-02-08 19:16:21 UTC

Looks like I'll be busy for the next 48 hrs https://image.nostr.build/5f06441fabe5125ff4500f9deb64efa73a00d6b1ab793ba05b2aa604f783d857.jpg

2023-05-06 07:42:14 UTC

Any decentralized system can be centralized if there’s only 1 of “the thing” running. e.g. ipfs node, bitcoin node, nostr relay, dwn etc.
The point is that you can run more than 1 of “the thing” by more than 1 party and still achieve the same logical state regardless of how many there are running.

2023-05-06 07:24:51 UTC

Check out how many fries my gyro came with. There’s almost 1 ketchup packet per fry.
To be fair, the menu did say “small/medium/large fry”, in which case I guess they gave me extra?
https://nostr.build/i/nostr.build_21979d79b97d5096a83c2c60e6376c0b8d38486c96f766881e31d7a561a35047.jpg

2023-04-18 00:35:53 UTC

- reply

Ah yeah that makes total sense. Thanks for the example.
Tossed up an issue on GitHub: https://github.com/TBD54566975/did-nostr/issues/10
Will put out a PR soon to nix the double hashing!

2023-04-17 16:45:04 UTC

- reply

In the meanwhile, here’s ChadGPT’s take: https://nostr.build/i/nostr.build_55544f758f9e505b015b16be7decde7f4380bc691a614c3d2699b8e601e8778f.png

2023-04-17 16:25:51 UTC

- reply

Heyo, great question. My rationale behind double hashing the recovery key commitment was to prevent against length extension attacks.
I’m not a cryptography expert though so there’s a possibility that double hashing might just be unnecessary complexity. Would be awesome to know for certain

2023-04-17 15:52:38 UTC

- reply

I’m a moederate.

2023-03-22 19:27:50 UTC

- reply

I really need to proofread before sending. I don’t think I said ‘telegram group’ enough times.

2023-03-22 19:04:39 UTC

It’d be interesting to see ChadGPT play chess against Bard.
Also kind of want to start a telegram group and invite Chad and Bard to a telegram group to see what they end up saying.

2023-03-20 00:40:23 UTC

- reply

I think the point #[2] is making though is: “an ion node isn't giving me any proofs that i can use to verify the legitimacy of a response" (definitely correct me if I’m wrong Colby)
if i send a request to an ION node to resolve a DID for me, what proofs are provided alongside the resolution result that would allow me to do any integrity checks?
Without these proofs, an ION node could just lie to me about the contents of a DID Doc and I’d be none the wiser.
an example that isn't ENS would be a DWeb Message or a Nostr event. they're independently verifiable. i can immediately do a sigcheck clientside and know whether the message/event is bunk.
it seems like ION node does have these proofs because they’re required in order to anchor a DID (e.g. self certifying inception event). it just doesn’t return them currently.
If they were returned as part of a resolution result (or could be requested separately) a client would have everything needed to verify legitimacy I think.
Or is the expectation to run your own ion node if you want to verify? Which is a significantly heavy lift

2023-03-19 03:17:41 UTC

Wish I had time to make it out to Nostrica. It’s going to be incredible. Can’t wait to see all the cool ideas/stuff that people come up with together.
To everyone there, hope y’all have a blast.

2023-03-17 20:03:18 UTC

- reply

#[6] imo, the primary benefit of ION is the censorship resistance provided by the anchor to Bitcoin.
Operationally, the lift to run an ION node is probably too high for most to consider actually running one primarily because of how tough it can be to run a reliable IPFS node. Given the high barrier, i feel that the likelihood of there being many ION nodes to choose from is low. This paired with the high likelihood that ION DIDs will almost always be resolved by ION nodes instead of clients/light wallets manually doing what an ION node does for you sort of nullifies / diminishes the censorship resistance provided by the anchor to Bitcoin.
Generally speaking, i think reducing the # of intermediary servers/nodes that have to be relied upon to resolve a DID is the best path forward because it decreases the likelihood of getting tricked (e.g. your example an ION node tricking a user) or being censored.
If there have to be intermediary servers/nodes in between, the hope would be that running that server/node is dead simple / ezpz as a means to increase the likelihood of many people/businesses actually running them. people already don't want to run servers so the barrier is already high.

2023-03-17 15:15:20 UTC

- reply

it is yep. did:nostr only uses nostr. dids are resolved by relays

2023-03-13 06:25:47 UTC

- reply

Included a full jank prototype to see if the thoughts made any sense when translated into code.
Still WIP but idea is starting to take shape. Hoping to implement it into a client and relay soon to get a feel for whether it’s actually useful

2023-03-13 06:16:00 UTC

Braindumped thoughts around how DIDs might work on nostr: https://github.com/TBD54566975/did-nostr

2023-03-13 06:10:42 UTC

Nostralia

2023-03-13 04:06:00 UTC

I think ChadGPT is a better name for ChatGPT. Can then say stuff like "go ask Chad" or "Chad said..."