GM from my home office, #coffeechain.

Well used tumbler from my favorite coffee shop back in my old home town.

Nostur

https://apps.apple.com/us/app/nostur-nostr-client/id1672780508

Audiobooks require much more production than simply making the digital file available for the text version. Unless you are buying it as a package with the book, and therefore paying more than for the book by itself, this would not make sense.

Yeah, it's not just about your channel partners having a beefy channels, though. The liquidity in their channels has to be available in the direction you need it.

1m sats is a pretty large amount to be moving on Lightning. Bear in mind that if Bitcoin even just overtakes gold's market-cap, that would be the equivalent of moving over $8,000, even though it's currently only a bit over $600.

That mystery has been bugging me for a while, thank you sir!

How do I add recommendations such as this one for highlighter.com to my profile?

#Amethyst #AskNostr nostr:nprofile1qqsyvrp9u6p0mfur9dfdru3d853tx9mdjuhkphxuxgfwmryja7zsvhqpzamhxue69uhhv6t5daezumn0wd68yvfwvdhk6tcpz9mhxue69uhkummnw3ezuamfdejj7qgwwaehxw309ahx7uewd3hkctcscpyug

That makes a lot of sense. Still very fast when zapping a non-coinos wallet (Strike), so all good now!

Absolutely! Took barely a second to register the zap on Amethyst!

Probably a liquidity bottleneck between your channel partners and the sending wallet, would be my guess.

Grace toward your spouse as a fellow sinner forgiven by God is absolutely paramount in marriage.

Sure, anything that automatically adjusts based on the prime rate+margin.

Those locked into fixed rates may want to wait for more reductions before refinancing and it will take some time for FIs to adjust their rates accordingly.

Looks like Amethyst is working intermittently, now. I can zap, and the funds come out of my coinos wallet, but it's spotty on whether it shows up as a zap or not.

What about Alby Go? That just isn't connecting at all. Or is that functionality via NWC part of what isn't yet enabled?

NIP-46 defines how to do remote signing using Nostr relays as the infrastructure for sending pre-signed and signed information back and forth between the signer and the client.

NIP-50 defines how clients should perform search queries from relays.

And nostr:nprofile1qyvhwumn8ghj7un9d3shjtnddakk7um5wgh8q6twdvhszythwden5te0dehhxarj9emkjmn99uq3kamnwvaz7tmjv4kxz7fwdehhxarjwpkx2cnn9e3k7mf0qyvhwumn8ghj7un9d3shjtnndehhyapwwdhkx6tpdshszymhwden5te0wahhgtn4w3ux7tn0dejj7qg6waehxw309ac8junpd45kgtnxd9shg6npvchxxmmd9uqjqamnwvaz7tmjv4kxz7fwdehkgetjw4hxuetjwvhxuet5wahhy6e0qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qghwaehxw309aex2mrp0yhxummnw3ezucnpdejz7qgwwaehxw309ahx7uewd3hkctcqyqlhwrt96wnkf2w9edgr4cfruchvwkv26q6asdhz4qg08pm6w3djgqzm5c4 covered what a NIP is. 😊

Why is the relay format in the NWC string "wss%3A%2F%2Frelay.coinos.io" instead of "wss://relay.coinos.io"? Not sure if this has anything to do with my trouble connecting it, but I can't seem to get it to connect to either Amethyst or Alby Go.

NIP-46 is the way!

*So I guess we are done with 58K for now...

ftfy

We should never expect that relay owners won't censor content they don't like or that they consider spam.

We should expect that not all relay operators will agree and use multiple relays in order to post and to see the content we want.

Relays MUST find a way to block spammers or they will simply be unable to survive.

Call it censorship, if you want to, but #Nostr 's censorship resistance always has been and always will be that you can use multiple relays and even run your own where you get to decide what will stay on or get booted off your relay.

GN frens. Until tomorrow.

Who?

nostr:npub12ctjk5lhxp6sks8x83gpk9sx3hvk5fz70uz4ze6uplkfs9lwjmsq2rc5ky and PSA. Quite the combo.

I must say, #Mastodon is a very sharp looking #Nostr client on Android.

Why not just let Amber on your phone handle signing for the web apps you use on your laptop?

Yes and no. As I understand it, not just anyone can see your IP. Only those you are intentionally connecting with. So it's not like kind4 DMs, where anyone can see exactly who is talking to who. And even your peer doesn't get your actual IP if you are connecting via a VPN according to nostr:npub1h5t3asu90f2x48rxtcqkjvwhza7m6kngs7vjyanx8xqyswc6es2s4645z5 who is much more familiar with the protocol than I could ever hope to be.

So... How do you get that follow if no one sees what you post because you aren't in any web-of-trust?

LOL! My Cheesy PB&J recipe ended up in your slides!

I absolutely would love to set something like this up, preferably running on my own hardware, but I have always tended to be more of a power-user for everything I get into, including Nostr.

I don't expect most users are going to have any desire or aptitude to set up their own relay that can do this for them, not unless it is dead simple to spin up and walks them through it like a 5th grader.

I guess it depends on what we mean by "smart."

They are going to need to have some form of being "smart" in order to weed out spam without weeding out new, legitimate users along with it. They are also going to need to have some form of being "smart" to properly handle reports of illegal content, without leaving opportunity for "report spam" to make the reporting useless.

Outside of that, how smart the relay needs to be will depend on the use-case. There are relays out there that don't store kind1 notes at all. The only reason they exist is to store NIP-47 defined kinds to facilitate Nostr Wallet Connect transactions. Part of such a relay being efficient is being smart enough to refuse all other event kinds. On the other end of things, clients need to be smart enough to only reach out to the specified NWC relays when looking for those event kinds, and not when looking for other event kinds.

So, I think both clients and relays are going to need to have a certain level of "smarts" in order for both to be efficient. But that can definitely go overboard, trying to do too much processing on either the relay side or the client side is going to make them inefficient and unreliable.

I don't think privacy and censorship resistance are necessarily inversely related like this, such that something being more private must be less censorship resistant, and things that are more censorship resistant must be less private.

You can have things that are neither very private at all or censorship resistant, such as Twitter and Facebook.

You can have things that are very censorship resistant, but not very private, such as #Nostr.

You can have things that are both censorship resistant and private, such as Keet.

And I would assume you can have things that are very private, but maybe struggle to be censorship resistant, which the founder of SimpleX seems to say applies in that case.

nostr:nevent1qvzqqqqqqypzqn4csvgddd8djhrdv63etv7nea2ehp06aj8hdyw6l4q94yhq2htdqqs82u5gxj95wdnv822my8a4l7duhjvltchdvpyafg3q2efkdv8f5cgtfvjmj

There are some things that need to be implemented by both client and relay in order for them to work properly, but there's plenty of things relays can implement on their own without clients needing to do anything at all.

I think one of the most important things relays MUST do for their own continued existence, is mitigate spam as best they can, or else they will quickly fill up their data-stores with garbage that no one wants to see. Each relay must determine for itself what it considers to be spam, and the methods they use to combat spam should require as little cooperation from clients as possible. That said, they should be able to implement things like PoW as a spam mitigation method and expect clients to support it, because that has been a core NIP for quite some time. NIP-13, as a matter of fact. See the details here: https://w3.do/Z86qR9oX

Another thing relays should do, for their own safety, is moderate reports of illegal content being hosted on their relay. Unless relay operators are VERY good at concealing their identity and hosting the relay in a way that cannot be traced back to them, they could face serious legal consequences if they do not remove illegal content, but continue to allow it to be available from their server.

I do want to respond to a few other things you mentioned directly.

"It seems to me that more people will run clients than relays..."

This is ABSOLUTELY true, and clients should give their users a lot of control over what they see, regardless of what content is available on the relays users are connecting to. It's a both/and, rather than an either/or when it comes to whether spam and other unwanted content should be filtered at the relay or client level.

"And you can only connect to relays that implement all of the features that your client expects..."

This is not the case. You can connect to any relay, regardless of whether it has features your client supports. How useful that relay will be to you will depend on what your client supports, though. For instance, you might connect to a PoW relay that allows anyone to read what is stored on it, but requires a certain amount of PoW to write to it, unless you are on a white-list. If your client does not support NIP-13 it will simply be unable to write any of your notes to that relay. It will still be able to connect to it and read from it just fine.

"OTOH, pushing all of the complexity into clients results in fewer clients that are harder to build..."

This may not be the case. Not every client needs to have every feature. I don't need #Amethyst to have a Nostr integrated podcast player built into it. I have nostr:npub1v5ufyh4lkeslgxxcclg8f0hzazhaw7rsrhvfquxzm2fk64c72hps45n0v5 for that. I don't need it to have a music player that lets me zap the artists, that's what I have nostr:npub1yfg0d955c2jrj2080ew7pa4xrtj7x7s7umt28wh0zurwmxgpyj9shwv6vg for. I don't need it to have a news aggregator built into it, because that's what Layer3.news is for. I don't need it to have a recipe directory built into it, because that is what nostr:npub1xxdd8eusvdxmaph3fkuu9x2mymhrcc3ghe2l38zv0l4f4nqp659qskkt7a is for. And I don't need it to have a marketplace built into it, because that's what nostr:npub15dc33fyg3cpd9r58vlqge2hh8dy6hkkrjxkhluv2xpyfreqkmsesesyv6e is for.

We can have a bunch of clients that are very good at ONE thing, rather than relying on one client to have ALL the features. There will always be some clients that try to pack as many features in as they can, but at some point they have to pare it down for the sake of not overwhelming their users or making the client super-sluggish, because it is trying to load so much data all the time.

"But what really matters is that it doesn't matter who does what where because it's all an open protocol and gfy we're living in the future! 🤙 🚀"

I WANT TO ZAP YOU FOR THIS! YES! We're all going to do whatever we think is best, and the things that work will live on while the things that don't work will die.

Let's see if this equally applies to relays.

You are able to choose which relay to connect to. - True

You are able to run your own relay. - True

You can even write your own relay software. - True

If there is a bug, you can switch to another relay until it is fixed. - True

Depending on your circumstance, you can choose between convenient relays or secure ones. - True

"Relays are shared by everyone." - Not true

Relays are shared by those who choose to connect to a given relay. Someone may choose to run their own personal relay that only they can post to in order to back up their own notes. Or, they may run a relay to back up their notes and all the notes they care about from others (anyone they follow) that they also allow others to read from, but not write to. Or they may run a relay that is only for a small group of people to read and write to, such as their church. Or they may have the hardware and bandwidth that can handle running a large public relay that anyone can post to or read from, but even then that does not mean everyone will use it.

Relays are just as diverse as clients, if not more so, and users have a lot of choice about what relays they will connect to, or even run their own. So again, I see no real reason why users should trust clients more than relays.