Found a little hole-in-the-wall sandwich shop in Amsterdam and it has ruined every other sandwich for me, they were so good!

Walking in Amsterdam. I have never been more scared of bicyclists in my life.

Next stop: Prague. But the flight isn't for several hours. View quoted note →

GM Nostr (again). Landed in Amsterdam. It's my first time in continental Europe and my wife and daughter's first time overseas.

@Kagi I was unable to find any relay list for your npub. If clients that use outbox are trying to find your notes, they won't know what relays to look on if your relay list cannot be found. If you want your notes to be seen by those following you, you should publish a relay list (kind 10002) from most any Nostr client.

GM Nostr. Headed to the airport. ✈️

Shakespeare does a bangup job creating websites with Nostr integration! What models are y'all getting good results from without breaking the bank? Claude Opus really chewed through my credits creating a pretty basic blog site. #asknostr

Forgive the article spam from me over the next few minutes. I am updating my articles with some hashtags that I am hoping will make my new blog site automatically categorize them.

Wonderful Lord's day worshiping with God's people here in North Idaho! Will miss them over the next two Lord's days, but looking forward to seeing the Holy Spirit work in the hearts of those who hear the gospel in Prague!

Pretty hilarious. My Nostr license says I joined back in 1975. I believe that's because I was messing around with posting notes with false timestamps.

Some of y'all got some long dead relays in your relay lists.

Nostr Devs, I chatted with @The Bullish ₿itcoiner about this last night, as I have been testing out his new client #Circl, but it bears notice of any client dev that supports lists of various kinds (relay lists, mute lists, bookmark lists, etc) in their client, or who plan to in the future. NIP-51 states that these lists "can be public or private" and therefore may have plain text entries, or encrypted entries in the "content" field. It does not specify what list kinds may or may not have encrypted data. Therefore, your client should be able to handle encrypted data in almost any of them. NIP-51 also says, "When new items are added to an existing list, clients SHOULD append them to the end of the list..." Appending only adds information, it does not remove any information that is already there. Adding an item to a list should never result in the loss of existing entries from that list, encrypted or otherwise. If Nostr clients fail in this, Nostr interoperability and user experience suffers. Here is what I would suggest: Minimum: Your client should not overwrite encrypted data when adding a new entry to a list that has an encrypted payload in the "content" field. Leave that field there and as is if your client isn't set up to utilize it. Better: At least decrypt and display the data to the user, so they don't think their whole mute list has been nuked because your client doesn't display the encrypted entries. And when your client is used to add new entries to the list, leave the encrypted data alone. Just add a new plain-text entry if you don't want to support adding encrypted entries to lists. Best: Not only display the encrypted entries to the user, but indicate in the UI which entries are public and which are private. When the user wants to add a new entry, present them the option to add it as public or private. There are certain lists this does not apply to, because their content has to be public for the list to function, such as kinds 10001, 10002, or 10050. However, the vast majority of other list types often do contain encrypted entries, especially since one of the most popular Nostr clients (Amethyst) is encrypting a lot of these lists by default. The most common way I have personally had list entries get nuked lately is from clients that did know what to do with encrypted entries in the "content" field of my mute list, my favorite relays list, and my search relays list. Things like this are what make many people feel like Nostr is broken, when it's just that client devs aren't paying attention to NIP-51 when they implement lists. #devstr #ndoc