Ok, so I would need a second device for testing such things, right?
nostr:nprofile1qqsth7fr42fyvpjl3rzqclvm7cwves8l8l8lqedgevhlfnamvgyg78spz3mhxue69uhhyetvv9ujuerpd46hxtnfduq3qamnwvaz7tmwdaehgu3wwa5kuegpz4mhxue69uhk2er9dchxummnw3ezumrpdejqj9swg4 I made a second ID in Keychat. However, when I try to write to it, it wouldn't show up in the chats of that second ID. Also, it didn't let me add the second ID as a contact using the npub, only using the QR code string. Is this intended or a bug?
nostr:nprofile1qqsyvrp9u6p0mfur9dfdru3d853tx9mdjuhkphxuxgfwmryja7zsvhqpzamhxue69uhhv6t5daezumn0wd68yvfwvdhk6tcpz9mhxue69uhkummnw3ezuamfdejj7qgwwaehxw309ahx7uewd3hkctcscpyug it woul be really nice if Amethyst could detect cashuB format and show a "redeem" button...
🙏
🫂
🥜
Maybe don't actually replace NIP-04 since it's in Keychat already, even if deprecated, but have both NIPs implemented, each with its own warnings. So Keychat could have Signal-encrypted chats, normal NIP-04 chats (both already in) and NIP-17 chats.
It seems Coldcard can create Nostr keys as well. Maybe ask nostr:nprofile1qqsw3znfr6vdnxrujezjrhlkqqjlvpcqx79ys7gcph9mkjjsy7zsgygpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsz8thwden5te0dehhxarj9ekh2arfdeuhwctvd3jhgtnrdakj7qgkwaehxw309ajkgetw9ehx7um5wghxcctwvshspg7dju
nostr:nprofile1qqsfx5v0j80628v2euujzlxu60fve5tcgv7tneerdp2y4txhgykt2rqpz4mhxue69uhkummnw3ezummcw3ezuer9wchszu00yz Something seems to be very wrong with Timechain calendar the last days. Each time you release even the smallest update, I have to delete all website data and then reload it. Otherwise, the site would only show a small dark grey loading circle and show nothing.
Would it be possible to implement a reload button that is loaded and shown before everything else? You could make this button to delete all cookies (and other website data?) and reload everything. Maybe make that button the offline part of the PWA as well.
Ok – so Signal is great. Good encryption, etc. Obviously, the main thing that we want to improve there is the centralized coordinator in the middle.
My original proposal was an adaptation of the Signal protocol for Nostr. https://github.com/nostr-protocol/nips/blob/2169fab971591d0b4a450ef08aeb6301c5d2a0da/104.md
But I got lots of feedback on that one that 1) group messaging needs to be first class and 2) multiple device support needs to be first class. Both of these are actually the same thing - supporting groups.
With the signal protocol, the way that the symmetric encryption works, when you're in a group, you're effectively creating a DM to every member of the group, encrypting it separately, and sending it out. Signal makes this feel like less of a big deal because they do some tricks on the server side to make it less heavy for the client.
In the nostr version of the signal protocol, you have no server to do work for you, so your device has to do all that work itself.
With MLS, because it's using a different data structure (binary trees) for managing encryption keys and users in a group, you go from a situation where group scaling is a linear problem (each new user in a group adds the same amount of work for all clients) to a log problem (where each new user in a group adds wayyyy less work for all clients).
There are also other benefits of MLS.
1) it's about to be an internet standard (like TLS, etc) so we conceivably get interoperability with other networks/clients
2) it's built to allow for the use of multiple ciphersuites and the graceful change/upgrade of the ciphersuites over time.
The only drawback is that it's very complex and very new. My work so far on getting MLS to Nostr has been focused on updating dependency libraries to allow for support of schnorr signatures over the secp256k1 curve (what nostr - and bitcoin - uses). I'm very convinced this is the right long-term solution for private messaging on Nostr but it's going to take a bit longer to get it probably ready for implementation.
If you haven't see it already, you can follow along with what I'm doing in my weekly posts. Also, if you're interested in working with me on all this, that'd be awesome.
nostr:naddr1qvzqqqr4gupzq9eemymaerqvwdc25f6ctyuvzx0zt3qld3zp5hf5cmfc2qlrzdh0qqxnzdejxy6rzwf5xvmnwveh25uk9n
There's a new app named Keychat that combines Nostr and Signal E2E encryption. https://keychat.io
nostr:nprofile1qqs04xzt6ldm9qhs0ctw0t58kf4z57umjzmjg6jywu0seadwtqqc75spzpmhxue69uhnzdps9enrw73wd9hszynhwden5te0wp6hyurvv4cxzeewv4eszynhwden5te0wfjkccte9enrw73wd9hsxv8qkt What do you think about this? So many wiki pages have already been written in Markdown.
There is one good idea in the comments for this pull. Instead of scrapping Markdown completely, define a separate kind within NIP-54 for Asciidoc wiki pages. That way it wouldn't break anything.
Yes, because NIP-54 defines Markdown for wiki pages. And thus, Amethyst uses Markdown (but missed wikilinks implementation).
Changing NIP-54 now to use asciidoc instead of Markdown could likely cause confusion and break anything. I think no one wants to rewrite everything in asciidoc. If anything, a new NIP for asciidoc would make more sense if you ask me.
He also banned the Elonjet account back then.
Please note that NIP-54 defines Markdown to be used for Wiki pages, in combination with [[wikilinks]].
Reporting?
It *has* "edit". But not all Nostr clients support it. One of those who do is Amethyst.
I could even propose an edit to a post that's not my own.
Amethyst supports kind 1010 editing events so you can basically edit a post to fix any misspelling or other things.
I wonder if online multiplayer gaming is possible in #Nostr, from simple things like #Chess up to more complex things like #BattleRoyale or #MMO.