Nostr Web Client

Whoa serious? Hard fork incoming?

Mosaic is an experiment not a fork. There are no clients and no users and I'm not going to advertise it. It could become a fork but I really don't want to fork nostr. Maybe down the line it will become a fork if we can't solve the problems in nostr.

What I want is to solve the hard problems. It is far easier to solve them free of the shackles of existing software (needing to be compatible, needing migration steps, etc). Just making something that solves these things is Step 1. Step 2 can be figuring out how to migrate from current nostr to the solution. Step 2 is far harder than Step 1. But trying to solve them both together in one fell swoop has not proven successful.

The current place Mosaic is at is probably unachievable for nostr. So Mosaic can work it's way back towards nostr, perhaps by first figuring out how to use secp256k1 keys in SSL. And of course nostr can simultaneously work it's way towards Mosaic, and they can meet in the middle somewhere.

Reply to this note

Please Login to reply.

Discussion

hodlbod 6mo ago 💬 2

I'm reading the spec now, liking it so far. I'm glad you separated general purpose flags, application specific flags, and tags. I'm not sure about human readable payloads, it seems like they should always be structured, especially since the only other place to put data is in tags, which is indexed (I think?) Also, limiting tags to 253 bits might be a tricky limitation for referencing URLs which might be much longer.

Mike Dilger ☑️ 6mo ago

Good point on the content-segment tags, since all outer tags are indexed, and these don't seem like they need to be. Probably have to rethink this part. I haven't really gotten to the higher layer stuff like that yet, beyond the rough first draft. I was imaginging application-layer tags (longer ones) inside of the content for stuff like this, but it's not written that way.

hodlbod 6mo ago

You'll also want to find a way to avoid duplicating tags if they need to be indexed but also used in content. Which means content likely needs to be able to reference tags in either place.

semisol 6mo ago 💬 2

secp256k1 is a permitted curve for X.509 certificates

You could allow any root that has the npub’s key, so it could sign sub-CAs or temporary keys for servers.

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 6mo ago 💬 1

it's gotta be the ecdsa public key tho, 33 bytes and all that. i didn't know that x509s can be secp256k1 tho. i thought r1 was the only one that most of the things permitted. TLS definitely. also JWT only r1.

semisol 6mo ago 💬 1

x-only pubkeys are prefixed with 02

it doesn’t matter though, you can flip it

Garbage nsec 6mo ago 💬 1

Not sure if x-only have a 02 prefix like same way compressed public keys do?

semisol 6mo ago 💬 1

No, you can prefix them with 02 to get a compressed pubkey.

Garbage nsec 6mo ago

Ah right, yup!

Mike Dilger ☑️ 6mo ago

When i tried to code it a few months back, I got stuck on some PKIX assigned number that didn't have an entry for secp256k1. But I'm recalling this from memory so I could be wrong here.