[Amethyst: Feature/Bounty draft] Implement user-controlled client side filtering of notes.
Is your feature request related to a problem? Please describe:
There is no great way to search or filter followed npubs’ notes by various criteria. Searching and filtering unfollowed npubs is a harder problem for another day I believe, though maybe I’m wrong about that?
Describe the solution you'd like:
On the home screen users should be able to tap a filter/search icon and customize the notes they wish to see. For example:
__
The filters should include a section for which npubs to include:
● probably defaulting to “all npubs followed by the user” which is like the current default view
● can also choose to filter down to just one or a subset of followed npubs
__
The user should be able to choose what type of notes they want to see from the selected npubs:
● just posts:
>> Excludes replies
● in-my-network conversations:
>>Excludes replies except replies to npubs the user also follows
● all conversations / all posts and replies:
>>Includes every note signed by the npub
● just posts and replies including all the selected npubs
__
The user should be able to filter by keyword. This is the hardest one I think because there are so many approaches especially when it’s more than one word.
● User should be able to (if following) select Jack’s npub (@npub1sg6plzptd64u62a878hep2kev88swjh3tw00gjsfl8f237lmu63q0uf63m), filter to all conversations, and filter with the keyword ‘nostrica’ for example to see all notes signed by this npub that include “nostrica”.
__
More examples:
● Filtering down to a single npub and then ‘all conversations’ should result in a timeline of notes that combines the “Notes” and “Replies” sections when viewing that npub’s profile directly.
● Filtering down to a single npub and then ‘in-my-network conversations’ should result in a previously unavailable view of just that npub’s posts and replies to all the other npubs the user follows.
● Filtering down to two or more npubs (all followed by the user, in this case Vitor and Will) and then ‘just posts and replies including all the selected npubs’ should show just the notes and replies from the any of filtered npubs which include all the selected npubs. This could be used to see all the notes published by either #[0] (Vitor Pamplona) or #[1] (Will of Damus) that include both of their npubs, so basically just a view of their public nostr conversations.
__
Obviously the naming of these labels and the UI/UX is a challenge. Ideally you could just type in natural language what you wanted to see and it would figure out the filters behind the scenes but I’m not sure I can fund a bounty for that level of feature..
Welcome any and all critiques #[2] #[0] et al.
Thanks
Try out Simplex for the group chat! Telegram has a troubled history..
Man cryptography is so metal
#[0] is this just an extension of NIP-26? Like delegation but permanently delegated?
#[2] I swear I saw you talk about this at one point, search on nostr is hard still tho
damn… I wanna know what he means
What I took away from the spaces and my own research is that:
- Wasabi has conflicts of interest by promoting a coordinator that directly funds Chain Analytics. They say it doesn’t matter because user can pick the coordinator but this is a false choice when liquidity determines the privacy “guarantees” (see below) of the mixing. Other coordinators have less liquidity, you’re hiding in a smaller pond.
- WabiSabi and Wasabi seem to use a fuzzy “anonymity score” system where the user sets this number in the client and their bitcoin mixes until it reaches the threshold. Problem is this number is poorly defined and it’s unclear what threshold you need to achieve privacy, there is no guarantee, it’s all fuzzy and depends on how the rounds turn out (see below)
- WabiSabi mixing is good at aggregating (and decomposing and recomposing amounts of) transactions on the *input* side but outputs still rely on this fuzzy logic anonymity score to “know” if your utxo is private enough. Outputs are not all the same amount like Whirlpool, so you’re only not guaranteed anon sets with known numbers of identical value utxos to hide among, instead outputs have variable amounts which can lead to low anon sets. The client would then remix again they say until privacy is achieved… this threshold is again poorly defined and makes assumptions about what chain analytics are able to probabilistically compute or not, a big question I have is how future proof are these probabilistic privacy thresholds users are setting today.
#[6] has alluded to this, I think he said he wanted to swap is keys eventually
I mean nip 26 sounds a lot better all around. What can I do to push that forward, any bounties?
#[5] #[6]
Maybe an advanced option when signing in, irreversible, ‘mark nsec as cold import’ switch to disable export for this particular case and users who want that
Yes but the point of this is to keep keys semi cold, not just transferring from one phone to another but from cold wallet to hot app
#[4] consider removing option to export nsec key that was imported via this cold import method. See GitHub discussion with Vitor and Seth on the bounty.
Vitor said: “We need to figure out how to do that well. Right now there is no difference between this method and others... I am wondering if this should be inside the QR itself, as an NIP19 option.
…
I kinda want to make that a NIP to make sure the behavior is consistent with all apps. It feels weird to block the exporting of something the user knows the app has. I am sure this will trigger a lot of people in the wrong way. If people lose their keys on the main device, but have their keys inside Amethyst, do we just let them rot?”
Re:
#[5]
And conversely, #[2] thought you do this already, Damus lacks a view into conversations happening ‘in-circle’ or maybe you could do it with adjustable degrees of separation filter.
Just clarifying since you said “via QR” at the end of your last reply. The text of the bounty says “When this approach is used, prevent export of the key in the app itself to provide better security around someone getting your nsec from your phone being open.”
So prevent export [entirely] just for keys that are imported in this way. Otherwise you go from cold to semi hot keys to fully hot. It’s an imperfect solution while we wait on nip 26 I believe.
No I think he meant not exportable *at all* based on how it’s written and just the whole point of this is to keep offline keys as offline as possible, if someone is using a HW wallet to generate the keys wouldn’t need to export them from a hot app at all
“When this approach is used, prevent export of the key in the app itself to provide better security around someone getting your nsec from your phone being open.”
?