> There's no protocol that protects against a malicious participant that shares the keys.
Correct, but that is not the point. The point is that a secret-based channel can be the target of multiple social attacks that play on people's lack of cryptographic knowledge on top of the usual secret managing mistakes people already do on a regular basis.
In this case, I am willing to bet that people will create a "My Chatgroups" Google Doc with all the active links to their most important chats. And if they need to share information that was discussed in the chat, they will share the link and enable other people to see everything without the other participant's approval.
The design is particularly bad for activists that don't or can't trust their counterparty from exposing them.
> The link sharing can be improved but I think this part is making reasonable trade offs and could be modified to prevent mistakes users might make without much trouble.
There are other solutions that don't need link sharing trade-offs: https://github.com/nostr-protocol/nips/pull/686
> I think its too easy to id what npubs are group chats, and subsequently who the participants are with taps on the relays.
Agree.
Hey nostr:npub1t3ggcd843pnwcu6p4tcsesd02t5jx2aelpvusypu5hk0925nhauqjjl5g4,
I prefer the UI and most features of Amethyst, but am constantly frustrated by it "getting busy" and ignoring all user inputs and freezing.
I've raised the issue with nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z multiple times, but sadly this is low on the priority list.
Wishing some bored dev would notice, compare the Amethyst code with other clients that don't have this problem (e.g. Iris), and release a patch/fix.
When Amethyst locks up like this, I have to wait for Android to suggest closing the app, then I have to "force stop" Amethyst, and then wait a while to restart...😢
It's not low in the priority list. It's just very hard to load everything we need to run the app effectively. Especially without a local database, which we are building. It's not something a "patch" would solve, unfortunately. These types of refinements require a weeks of background algorithms work. :(
nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z sorry if I'm bothering you.... But... Is all this necessary amber? Being that it aspires to be the app par excellence that safeguards our nsec beyond any client.
Or are these communications are inherent in contacting relays. Or something I am not understanding in my ignorance?
Amber is nostr:npub1w4uswmv6lu9yel005l3qgheysmr7tk9uvwluddznju3nuxalevvs2d0jr5 's work. You can ask him directly. If these things are indeed there, it's probably just an unforeseen mistake somewhere.
nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z amethyst has a weird UX quirk if we use three button nav where, from some notes displays, pressing the back button exits the app rather than going back to the main feed. Expected function on back button is to return to the previous display until finally landing in home feed. I never expect to leave the app with back button, but this is what happens.
It's a bug. I am hunting it down, but I couldn't find where the app is losing it's page stack :(
Yep, documentation is lacking. But the code is transparent. Anyone could write it.
Your profile. But you don't have any reports.
If people are not seeing your content, it's probably because they are not subscribed to the same relays you do.
Because we shouldn't even need a centralized webserver.
Yep, still on our to-do list. :(
Yep, media is stored with NIP 95
And since users love to paste these links on trusted platforms (Google drive, sms, etc) it's really difficult to see if the group is still secret.
Iris now supports secret chats that don't leak metadata, implementing the https://hrfbounties.org/ bounty #3. It works also for group messaging.
It's a quick & dirty solution, but works. A shared nostr account is created for the secret chat / group. Its nsec can be shared via link, qr code or invite message from a single-use anonymous account.
Users can then communicate using the shared account's messages-to-self. Iris signs the inner messages with your own key, but the arrangement could be used for anonymous group messaging as well.
I'll also add inner message encryption at some point, so you can ensure that only certain group participants can read the message.
This arrangement doesn't introduce any new event kinds and works also in clients that haven't implemented a special UX for it. You can just log in with the nsec and message yourself.
I had to disable the Iris social graph filter to let invites through, so now Iris DMs are open to spam again, but I'll try to figure out a better solution.
As always, the UX needs a lot of attention, but I believe here's an MVP.
Screenshots:
Alice wants to message Bob:
Alice sends a secret chat invite to Bob:
Bob automatically follows the invite from Alice. They can now message each other in the secret chat:
Here's how the invite looks in another client. I will add an "nostr:ninvite" URI in addition to the nsec.
The issue I have with this approach is that anyone with the shared link can see the conversation, past and future. People can share the link with coworkers or with the NSA and no one will ever know they are watching.
I would pay $15/m for backed-up long-term storage with NIP-95 media in it (capped at some good amount). Add a good search (NIP-50) implementation and you are gold.
I was just telling nostr:npub1de6l09erjl9r990q7n9ql0rwh8x8n059ht7a267n0q3qe28wua8q20q0sd and the viewers on his chat that I have just cleaned around 3 Gigabyte of cache on my smartphone. And for a stream while on carrier connection it took over 1 Gigabyte of data in a few minutes.
I don't think cleaning the cache does much these days. The OS fills it up with the latest from it's own cache. That's why the number goes back up very quickly.
Do those 12,000 events include Contact Lists? :)
The one I measured was for ~50,000 events from me or with a p tag on my user, with 7 indexes. But I am just doing the dumb storing of full hexes in the DB, which is not great.
A good use case is if you can download everything about your user (author + p-tags) to the phone.
Yep, but 250MB of just Nostr messages. Sum videos, photos, and translation models and we are up a few GB.
6 months of use and the local db of my user is already 250MB (uncompressed).
We dont even have apps for everything yet.
The history of Nostr will be defined by before and after local databases.
We will need bigger storage options on phones.
One unforeseen effect of doing the MediaPlayback in the background is that now when you kill the app via swiping up, it doesn't actually kill it anymore. The objects that were in memory are still there. The only way is to open Settings/Apps and Force Stop it there. :(
I am not doing anything crazy, just the usual SQL db. I might end up using your implementation as well. We will see.
Gotta finish Group Chats first, though :(