Braydon Fuller's avatar
Braydon Fuller
_@braydon.com
npub1r0ul...zzyc
"Do not give in to evil, but proceed ever more boldly against it." —Motto of Ludwig von Mises
It's unexpected that there is a trademark for JavaScript of which Oracle somehow claims. Cancelling the trademark would provide better clarity. Or perhaps we just switch to calling it ECMAScript 😂: Trademarks have usually been somewhat accepted as mostly harmless by many free software projects, however such above examples reveal the faulty logic.
Thinking more about a DHT for querying NIP-65 relay list metadata and had an idea. It could be possible to instead have a DHT-like protocol for relays for querying relay list meta data, where if the relay itself doesn't have it, it could ask their neighbors if they have it, and so on with a max hop count. However, rather than it being distributed by hash, it would be distributed by social connection and a web-of-trust.
When using multiple Nostr clients, wouldn't it make more sense for a "follow" to be its own event rather than editing one event with all follows listed. Multiple clients wouldn't conflict with each other and clobber the other because of stale information.
I want to briefly go over some great UI features of a few clients that help confirm identities and how I think it can improve. 1. Amethyst and Gossip both include an icon on the top right of the pfp to show that you follow that profile. With some exceptions, this helps identify profiles and which ones are honest and which are impostors. 2. Gossip also includes a number on the bottom right of the pfp to show how "connected" you are to the profile. This represents how many of your follows also follow the profile. So in what scenarios do these features not provide help? A. If the profile (maliciously or otherwise) changes their name, pfp, bio and etc (kind 0), it'll be difficult to know which one of your follows/contacts it was when you initially followed them. This could be used to impostor someone that could look "verified". A compromised private key is not a part of this attack and hardware signing or multi-sig will not help. Note also that Gossip does have a feature to enter a "pet-name" (I'm assuming this goes into the `kind 3` NIP-02 follow list) and this could be useful to help mitigate. B. If the private key of a profile is compromised (similar to A) all metadata can change. If notes (`kind 1`) start to appear from this profile that the private key has has been leaked; it will be difficult to recover and determine honesty and the original profile. For example, the Nostr Address (NIP-05) could have changed to the attacker's instead. C. If you're not following someone yet still want to be able to verify them, the followed mark will not help. However in the case of Gossip, displaying the "connected-ness" could help in this scenario. How can all these scenarios be mitigated? By having different levels of profile confirmation, starting with the least to the most: Level 1. Display "verified-ness" (or "connected-ness" as is current in Gossip) of the profile, this could be an icon on the pfp, however the exact number isn't as important as the names of the people that follow. For example displaying "Murray N. Rothbard" verified "Ludwig von Mises" has different value than "John Maynard Keynes" verified "Ludwig von Mises". This information could be displayed on the profile view. Level 1 will help scenario C. Level 2. Display if you follow the profile, at this point displaying Level 1 is less relevant now. This could also be an icon on the pfp and could replace Level 1. Note that having an option to jump all the way to Level 3 could be a UX efficiency improvement when a profile is followed. Level 3. Display if you have verified the profile. This will help scenarios A, B and C. The verified profile metadata will be duplicated and self-signed (either private or public). This could also be an icon on the pfp and could replace Level 2 and 1. Displaying that you've verified this profile on the profile view will also be helpful to provide clarity (including the specifics). Here is a possible UX implementation for profile verification (wire-frame animation): image Here is the NIP proposal:
TIL that Gossip supports private lists and Amethyst supports viewing public lists (not private nor their creation).
I've realized in Amethyst, in the general relays settings, you don't need to completely remove a relay from the list to stop incoming spam from it, you can just turn off all of the Home, DM, Global and Search icons.
This video had me wondering if there is or could be a generative AI that could find many different M.C. Escher type advanced tessellations. image
LLMs can be useful to determine comment relevancy for filtering too! Here is a basic demo: image