Last Notes
I see my mutes! Took a minute. I had to make a change to publish a new version of my list from Amethyst, so it must not have been able to find my previous one. Looks great now!
Search relays all loaded properly, too.
https://kojira.github.io/nostr-license/
I'll be away for a few weeks. Won't have opportunity to test anything new and shiny. Will definitely be excited to do so when I get back home, though!
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!
Some of y'all got some long dead relays in your relay lists.
Yeah, I had my Hermes Agent create a report on the read and write relays that my follows have listed in their kind 10002 and legacy kind 3 relay lists.
The first 25 or so ranked by number of npubs reading or writing from the relay is not bad. Mostly solid relays that are all still online. After that it goes downhill fast.
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.
https://relay.brightbolt.net/f4175b1ae4f8ccee11389f90c34dc665a8d511e9f730a79fcee26f846a0f0a10.png
I wouldn't recommend running NostrRSrelay on Umbrel as a public relay. It's intended to just be a private backup of your notes for a reason.
The GUI is on the same port as the relay, so if you expose the relay at 'wss://relay.yourdomain.com' the GUI will be accessible at the same domain, but 'https://', and NostrRSrelay has no authentication required to access the GUI.
Now, there's not much that someone can do from that GUI, but they can change out the npub whose notes are automatically backed up to any other npub... Then you end up with content hosted on your relay that you did not intend nor want.
Absolutely! If it's encrypted, it should stay encrypted unless the user actively chooses to publish it in plain text.
Very true. As a general rule for anyone just using the version available in Umbrel's app store, though, it definitely applies.
So, it will blast events that are written to it directly, but I assume not events that it aggregates, right?
New WoT aggregator relay?
"Git is..."?
Phone keyboard typos...
*Got it figured out.
Nostr Devs,
I chatted with @npub15yp…mpcx 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
For instance, here's a reply you made to @npub12r0…9qrx earlier that I have on my WoT relay. But @npub12r0…9qrx doesn't use my relay as an inbox relay, and I am not p-tagged in your reply.
But... @npub12r0…9qrx DOES use nostr.land, and the event cannon may be blasting to me.
I am sure @npub1syj…f6wl would appreciate that. He mentioned that he'd like to have it, but has been putting it off.
If you do, can you build in a retention window where it will delete notes older than X days, where the user can set the timeframe, and also the ability to select npubs that it never deletes notes for.
Oh, I know that part. My question was about your notes that DON'T tag me that have been showing up in my WoT relay.
Turns out, they're getting blasted there by nostr.land's event cannon feature.
Yes, the content is what matters, but in this case the question is what word was used in the original document. The word Jefferson used was "unalienable."
I want, but I probably won't have a chance to fiddle with that for a while.
Ok, that makes a whole lot of sense now. Thanks!
@npub10np…tl5h @npub1m64…uaks @npub1qyx…mu7u are you guys publishing or blasting to my WoT relay? How is it getting your notes?
Yeah, replies with me tagged, that makes sense. It's the kind 1 notes, or replies to other people who don't have my relay listed as an inbox that make less sense why I am getting them.
I do have it set as an inbox relay, but that would only explain notes where you've tagged me ending up on it. I have regular kind 1 notes from you without me tagged.
I bet it is the nostr.land blaster. @npub1226…grkj how does nostr.land determine where the event cannon will blast notes? Is my WoT relay one of the relays it blasts to?
Really? So all of the folks' notes on my wot.brightbolt.xyz relay, which is just my Nostr Relay Tray relay, are people actively choosing to publish to it? I thought for sure it must be aggregating them, because I have done absolutely zero advertizing of that relay, other than having it in my own relay list.
Except, it's actually "unalienable."
Source: https://www.archives.gov/founding-docs/declaration-transcript
You a Reformed brother too @nprofile…2yvq?
I see this list of relays on the right side of the page on desktop. Most of them are my inbox/outbox relays, but some of them are not on any of my relay lists. Are these the relays that #Circl is currently connecting to, and how is it deciding what relays to connect to in addition to my inbox/outbox relays?
https://image.nostr.build/b498962872516308beb83fdd7c6753aad0c4cd01da1e7fd5f19584309c2d1568.jpg
Git is figured out. Apparently it was restricted to Firefox Mobile with Glow as a PWA.
No issues when accessing through the regular browser UI, and no issues when using Brave either through the browser UI or as a PWA.
This leaves open the possibility that users simply won't realize that some of their list entries are public and some are private, but this can be indicated with an open or closed lock icon next to the entry in the UI, and tapping on it can display a message indicating that the entry is public or private.
Right? It really is Nostr in a nutshell.
Here's what I would hope for:
Client encounters a list, let's say kind 10007 since that's what we've been dealing with most recently, and it has a mixture of encrypted entries and public entries. It should parse the list and be able to display both encrypted and public entries to the user. This way users who didn't realize that a different client (Amethyst) was adding encrypted entries don't think that their list got nuked because they don't see anything where their search relays should be.
When the user wants to add a new entry to the list, the client should ideally offer them the option to save that entry as public or private. If you don't want your client to support adding private entries to the list, then at minimum it should just add the public entry and leave the rest of the entries already on the list in whatever state they are, public or encrypted.
The same should be the case for clients like Amethyst that want to default to adding encrypted entries to lists. If there are public entries already on the most recent version of the list, then the client should just add the new encrypted entry and leave the existing public entries unencrypted.
The curse of the fall made exercising dominion more difficult (see Genesis 3:17-18), but did not eliminate our mandate from God to "fill the earth and subdue it, and have dominion over the fish of the sea and over the birds of the heavens, and over every living thing that moves on the earth."
Of course, it won't be fully realized until the new heavens and new earth when the saints inherit the renewed creation as fellow heirs with our Lord Jesus Christ. Nevertheless, the ultimate fulfillment does not absolve us from our duty to exercise dominion now, when appropriate and possible.
How does Nostr Relay Tray find the notes that it aggregates when WoT mode is turned on? Is it just polling popular relays, then, rather than the relay owner's follows' outbox relays?
Yeah, it's tough to balance for some things. WoT, for instance, is only useful if follow lists are public. But then, if you want to follow someone privately, there are kind 30000 lists for that, which can have private entries.
Mute lists could be a good form of crowd-sourced spam mitigation, but then I don't always mute someone because they're a spammer, either. So maybe we should make reporting great again for those within our WoT to optionally use for hiding spam and such.
Relay lists in particular are an interesting case. Having some social indicators from your WoT around what relays might be good to use for search or for proxy relays, and what relays to avoid might be really good signal, but it should be the user's choice whether they want to "advertise" for that relay by having it as a public entry in those relay lists.
Yeah, I have noticed that Amethyst is pretty well defaulting to private for any NIP-51 list kind that does not absolutely have to be public.
I would check to make sure Satori can handle encrypted data in any of the list kinds you plan to support, except the ones that obviously would not have encrypted entries, like 10002 and 10050.
Nerd here. I have a couple different options for always-on NIP-46 signers, between Amber on my phone and Signet or Bunker46 on my Start9. Yet, I wouldn't know where to start with setting up a scheduler DVM.
I do agree that an always-on NIP-46 signer is probably not the solution for most users. Do most users have a need to schedule posts, though?
Got it. That must be the case, because nothing is showing up for me in #Circl. I am pretty sure I have a couple threads muted and a few words as well.
Yeah, but I probably could have had the same results with 90% of other clients that support kind 10007.
Seems most client devs don't realize that just about ANY list type can have encrypted entries, and I think @npub1gcx…nj5z philosophically believes most lists should be private by default, so Amethyst just encrypts every list that doesn't absolutely have to be public. I tend to agree with that approach.
Called it! Added search.nostrarchives.com as a search relay from a different client, went back to Amethyst and all my other search relays are GONE.
TIL that Amethyst encrypts kind 10007. Search relay list. So any client that doesn't look for and decrypt the "content" section treats it like you have no search relays...
Now for the fun of testing whether adding a search relay from another client will nuke the encrypted portion of the list. My sats are on, yes, yes it will.
Thanks for playing along. I was testing out @nprofile…qnef's new client's "Circles" feature.
Not supporting private mutes yet, I take it? My mute list shows as empty because they are all encrypted.
Nah, that's great. Created a circle of my Reformed brothers, and now I can poke all of them when I have theology to discuss. 😂
My daughter also got a great shot of the aurora tonight.
@npub15yp…mpcx #Circl is looking great! Haven't run into any issues so far while logged in via @npub1h0u…rwx8 on Android.
From what I can tell, posting something to a "Circle" just p-taggs everyone in that circle, but it is otherwise just a normal kind 1?
Q1: What is the chief end of man?
I seem to remember this being an issue for us in the past as well, back when I ordered a hoodie from you.
