Software Engineer • Bitcoin & Nostr • Economics • Security "Do not give in to evil, but proceed ever more boldly against it." —Motto of Ludwig von Mises Lightning self-custody with https://github.com/braydonf/satdress
Braydon Fuller @Braydon Fuller - 34m
nostr:nprofile1qqswuyd9ml6qcxd92h6pleptfrcqucvvjy39vg4wx7mv9wm8kakyujgpypmhxue69uhkx6r0wf6hxtndd94k2erfd3nk2u3wvdhk6w35xs6z7qgwwaehxw309ahx7uewd3hkctcpypmhxue69uhkummnw3ezuetfde6kuer6wasku7nfvuh8xurpvdjj7a0nq40 What's been your strategy for getting events for contacts that don't have NIP-65 listed relays?
Braydon Fuller @Braydon Fuller - 2h
Been running this for more than 12 hours now. There is still a fair amount of work to be done. Some contacts don't have a NIP-65 relay list defined, so notes are not pulled down for those yet. I'm not sure which specifically, but it could be useful to know what clients don't support listing them (at a minimum). How many discovery relays are too many and which have the most current info? Should such a relay as this attempt to pull in as many NIP-65 and follow lists for 2+ degrees of follows? Negentropy is useful to sync past events or what may have been missed while offline. There is support, however some contacts don't benefit from it yet as a relay that supports negentropy isn't listed yet.
Braydon Fuller @Braydon Fuller - 3h
I've noticed that Gossip has made it an option the merge, pull down or push up the local version. None of that would be needed if each was its own event because it would continuously be merged without a conflict.
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.
Braydon Fuller @Braydon Fuller - 18h
I need to run strfry with a config option to increase the timeout for the router. This should be in the next release; however, I have code for it now here: https://github.com/braydonf/strfry/tree/router-timeout Some related issues: https://github.com/hoytech/strfry/issues/45 https://github.com/hoytech/strfry/issues/127
Braydon Fuller @Braydon Fuller - 19h
Okay, this is awesome. I have the "outbox model" working in #amethyst today. It's using a topic relay that pulls down events for everyone that I follow. It's using `strfry relay`, `strfry router` and `strfry sync` with negentropy. I have a set of tools to create the necessary config files. It's very much a work-in-progress; however, I'm currently using it now for my relay and already I see notes coming in via it, so great to see. The early code is here: https://github.com/braydonf/strfry-tools cc: nostr:nprofile1qqsyvrp9u6p0mfur9dfdru3d853tx9mdjuhkphxuxgfwmryja7zsvhqpzamhxue69uhhv6t5daezumn0wd68yvfwvdhk6tcppemhxue69uhkummn9ekx7mp0qyghwumn8ghj7mn0wd68ytnhd9hx2tcewvzaw
Braydon Fuller @Braydon Fuller - 22h
I concur. I also accept sats instead of time.
Braydon Fuller @Braydon Fuller - 1d
NaN?
AOSP software distribution did many things well, dev signing APKs was a good move. Having an app with a dependency of another on the other hand, is something every GNU/Linux distro has done so much better. In my opinion, some of the Nostr functionality should be much closer to the OS, and a Nostr distribution of AOSP (like a fork of GrapheneOS) will be an inevitable solution.
Indeed, just finished reading it, and recommend it. Will have to listen too sometime.
Braydon Fuller @Braydon Fuller - 3d
The hamburger patty "hack" is funny, but works.
Could be, could not be. Reminds me of monolithic vs microkernel architecture arguments of kernels. Today both are used as well as hybrids. The monolithic Linux kernel has its advantages. Space for all approaches.
By the way, I'm planning to work on implementing these ideas soon after I finish some work on strfry tooling. However, I wanted to get them documented early (for discussion, improvements and etc.)
From "The Allegory of the Swamp" Appendix A of "A Lodging of Wayfaring Men": "No, to get out of this, we will have to fly in defiance of our feelings, and think. The truth is that most people will do almost anything rather than this."
Engineers working on what they think, or their customers think, is important while others disagree with them, who are not their customers or manager, is what makes Nostr great. Value is ordinal and not cardinal and determined at the margin. Carry on!
Braydon Fuller @Braydon Fuller - 4d
From "The Allegory of the Swap" Appendix A of "A Lodging of Wayfaring Men": "No, to get out of this, we will have to fly in defiance of our feelings, and think. The truth is that most people will do almost anything rather than this."
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): https://raw.githubusercontent.com/braydonf/nostr-key-migration-and-revocation/89a9437e958f44bf748f145b85e603d83cf7ef2f/graphics/ux-storyboard-animation.webp Here is the NIP proposal: https://github.com/nostr-protocol/nips/pull/1499
The strfry websocket library is using an event loop with libuv, I'm a fan, good stuff! https://github.com/hoytech/uWebSockets/blob/master/src/Libuv.h
This is great info! The fat:protein ratio especially as well as including bone broth and etc. nostr:nevent1qqsqhx39nkwq7cxsc06txjc0hplzxe3uuzgwjt5lrns5dqqzq42ltdqpzemhxue69uhhyetvv9ujumt0wd68ytnsw43z7q3qkyk7ac33apd7cx0nun3laevf84zfhr8pt8kj4h8v7cpx9t72d4gqxpqqqqqqzncc89t
Cool, are you using negentropy at all yet? Code for this available any place?