justin

Reading NIP-05. The `nip05` metadata field is split into `local-part` and `domain`. Then the client makes a GET request to `https://<domain>/.well_known/nostr.json?name=<local-part>`

2022-12-25 15:07:07

- reply

Did you ever find a non-custodial alternative?

2022-12-25 14:55:41

- reply

This sounds like it would be useful, but it would require the client to shadow add the relay and fetch events from it.

2022-12-25 14:51:52

- reply

How did the universe begin?

2022-12-25 04:50:16

- reply

👏

2022-12-25 01:01:10

- reply

This message is a sign that now is the time!

2022-12-25 01:00:32

- reply

I was just thinking that I really need to get to it. 🙋‍♂️

2022-12-24 23:54:26

- reply

One, probably bad, idea would be to include just a prefix of the pubkey in tags to add some privacy. Then clients could throw out messages that might be for you but fail to decrypt.

2022-12-24 23:52:40

- reply

I can’t think of a way to avoid this without a completely different architecture for DMs.

2022-12-24 23:51:32

Reading through the NIPS. According to NIP-04, encrypted messages are just a special kind of event with an encrypted payload. This means that data about who you are DMing with (and when) is public, though the content of those messages is not.

2022-12-24 17:10:36

- reply

Oh. That sounds fun. Need a separate app?

2022-12-24 17:06:55

- reply

What is chestr?

2022-12-24 16:53:59

- reply

Yeah, and hopefully clients will eventually be pretty robust to slow relays. Fetch in parallel, without blocking a thread, timeouts, etc.

2022-12-24 16:52:20

- reply

More network requests. Might make things a bit slower, but shouldn’t be too bad. Let me know how it goes.

2022-12-24 16:33:04

#[0] Verifying My Public Key: "ninjudd"

2022-12-24 16:12:48

- reply

🥶🥶🥶

2022-12-24 16:05:53

- reply

51° 😬 but about to fly to 21°

2022-12-24 15:25:41

- reply

gm. how cold is it where you are?

2022-12-24 07:33:47

The Nostr relay architecture is actually pretty similar to email, except without individual inboxes being stored on relay servers.

2022-12-24 07:02:10

- reply

Just had a random thought: if Twitter was built on Nostr, and you decided to go build a new Twitter, it would be impossible to prevent contagion from the original Twitter without changing the protocol. Not only is censorship impossible, but so is the creation of echo chambers.

2022-12-24 06:53:13

Imagine a world where Xcode’s build pipeline was purely functional, so you could verify that an open source app you’re running exactly matches a specific tag in the source code.
That would be pretty cool.

2022-12-24 06:34:58

- reply

May be useful for tagging people you follow, once autocomplete is implemented.

2022-12-24 06:31:20

- reply

Actually, usernames aren’t unique. I thought I was the first Justin, but I’m not ☹️

2022-12-24 06:30:35

- reply

Welcome, first Chris!

2022-12-24 06:25:34

- reply

Yeah, I like humans doing the forwarding. I assume that’s what happens when you boost something, right?

2022-12-24 06:20:46

- reply

Good point. There’s nothing to prevent a Relay from forwarding a note. It just isn’t required for nostr to work.

2022-12-24 06:16:36

- reply

Shaka?

2022-12-24 06:12:13

- reply

So to prove a message was created before a time, you hash the content and add to blockchain. To prove a message happened after a time, you include a hash of a block in your the metadata.

2022-12-24 06:09:05

- reply

Ah, got it. So you hash the content and then add that to the blockchain. Makes sense.

2022-12-24 06:03:15

- reply

You may be right. But it’s also pretty genius to just punt that problem until later :)

2022-12-24 06:00:29

- reply

Interesting. Need to read about OTS. Would this prove the content existed before the timestamp, or that it was created after the timestamp? I can’t think of a way to prove something happened before, but maybe I’m not thinking hard enough.

2022-12-24 05:56:16

- reply

If someone publishes a server recommendation saying they are moving to another relay, should the client auto-add that new relay? That’s how I imagined it would work, otherwise you may not notice that someone moved, if you miss their last message.

2022-12-24 05:50:59

- reply

One solution would be to have a trusted time oracle that outputs a signed chain of timestamps that everyone includes in their posts.

2022-12-24 05:50:14

- reply

Curious if people have ideas how to cryptographically validate time of posting.

2022-12-24 05:49:15

- reply

Requiring a chain of updates, like SSB, mostly solves this. You at least cannot insert a post in between other posts after the fact.

2022-12-24 05:47:15

- reply

It could be enforced on the Relay, but then you have to trust the Relay.

2022-12-24 05:37:31

My biggest question about #nostr so far:
Does the number of Relays you have to subscribe to grow really large over time, and will this affect performance?

2022-12-24 05:34:34

Can someone explain #plebchain to me?

2022-12-23 21:33:24

- reply

Did you convert the key from Damus to hex? Can do it here https://damus.io/key

2022-12-23 21:09:21

- reply

Or maybe there’s a separate moderation layer, so you can select a moderation policy independent of Relays.

2022-12-23 21:08:26

I could see the choice of Relays on Nostr eventually becoming a way to self select a specific moderation policy. Want a specific type of content filtered out of your stream? Choose a Relay that removes that content.

2022-12-23 20:18:35

- reply

Is this the real one? #[5]

2022-12-23 20:13:32

Hello world. I’m a programmer named Justin. I lead the Product team at Bird.
Been thinking a lot about how to do distributed Twitter right. Nostr is the closest I’ve seen so far.
#introductions

2022-12-23 20:01:41

Nostring