Dikaios1517

https://w3.do/cyEotFaN

│Christian│Husband│Father│Presbyterian│Bitcoiner│

In that order.

Public Key

npub1kun5628raxpm7usdkj62z2337hr77f3ryrg9cf0vjpyf4jvk9r9smv3lhe

NIP-05 Address

dikaios1517@nostrplebs.com

NIP-57 Address

dikaios1517@nostrplebs.com

Profile Code

nprofile1qqstwf6d9r37nqalwgxmfd9p9gclt3l0yc3jp5zuyhkfqjy6extz3jcpzpmhxue69uhkummnw3ezuamfdejszxnhwden5te0wfjkccte9e38y6t8dp6xymmvwshxuet5ym9hzy

Publishing to

nostr.wine

relay.brightbolt.net

relay.damus.io

Author Public Key

npub1kun5628raxpm7usdkj62z2337hr77f3ryrg9cf0vjpyf4jvk9r9smv3lhe

Show more details

Last Notes

2025-04-09 18:11:32

- reply

This is really shaping up!
What is the remote signer option you have for log in "with your NIP-05 address." It doesn't appear to work for me. Is it using NIP-46?
My suggestion would be to offer remote signing login similar to the way @npub1jlr…ynqn and @npub1ye5…knpr have implemented it with Coracle, Flotilla, and noStrudel.

2025-04-08 05:41:05

- reply

Yes, but they were very new channels. You also aren't "asking." You just open the channel. If they don't want to keep it, they just close it.

2025-04-07 20:55:22

- reply

They're working on integrating Nostr Wallet Connect. Until then, you would need to use their wallet.

2025-04-06 03:24:24

- reply

Do relays advertise which NIPs they support? That one is what? NIP-70?

2025-04-06 03:23:30

I couldn't code my way out of a paper bag, but maybe one of y'all can help out?
#nevent1q…4npg

2025-04-06 00:41:08

Was great to hang out this afternoon and talk Bitcoin, Nostr, faith, and whatever else came up over drinks and smokes.
Relieved some FOMO from not being able to go to Bit Block Boom this week. 😂
#nevent1q…htsy

2025-04-05 20:12:55

- reply

Welcome to the StartOS family!

2025-04-05 19:56:21

Loving the update to Jumble.social @npub1syj…f6wl!
One thing I am noticing, though. Now that "favorite relays" load in the right-side panel, you cannot select to send a note to only that relay. You first need to add it to a relay set, so it will show up in the left-side panel, and then Jumble will display the toggle to send your note only to that relay.

2025-04-05 19:42:33

- reply

Always happy to see other Reformed Christians on Nostr!

2025-04-05 19:19:58

- reply

How far the mighty have fallen... There's a few of us Reformed folks who are keeping the hardcore side of Protestantism alive. 😉
H/T to @npub1ak5…0gwg on Nostr in particular.

2025-04-05 19:02:22

- reply

The tutorials @npub1utx…50e8 has in the readme for each of his Bitvora relays aren't too bad for someone who is a bit technically inclined.
We definitely need someone who can make some more approachable tutorials for some of these things, though... Like a Nostr version of @npub1rxy…hnp8, except that I prefer written format for tutorials, with screenshots and maybe some short clips for each step. Videos can be a pain to find there a section that you want to go back to started to watch it over again, while written format, you can just leave the section you need up on the screen.
I might be biased though. I write all the procedures for my department with my current employer using this format, and they are basically just tutorials by another name. They also take an incredible amount of time to do well, which is probably one of the major reasons why devs don't write them for their own projects. Their time is tied up building and squashing bugs.

2025-04-05 17:33:51

- reply

We are doomed to forever have multople DM specs that some apps support and others don't. 😭

2025-04-05 17:30:58

- reply

Easiest relays with a GUI are @nprofile…nggv's hosted relays at https://relay.tools and @nprofile…l3vp's Nostr Relay Tray.

2025-04-05 07:40:40

- reply

Good thing I have them backed up as lists. 😉

2025-04-05 04:12:06

- reply

Fair, and UTXOs of a few hundred thousand sats are probably fine. 😂

2025-04-05 03:24:32

This man... So quick to fix things when reported to him!
#nevent1q…3y3l

2025-04-05 02:42:02

- reply

Indeed. It's a relay that whitelists who can post to it based on your web-of-trust. In most cases, that is defined as the nostr:npubs you follow + the nostr:npubs they follow.
The one I am running is @npub1utx…50e8's WoT Relay that can be found here: https://github.com/bitvora/wot-relay
This implementation has the advantage that it can aggregate notes from those within your web-of-trust by pulling from the relays they write to. You can also limit the amount of time they will be stored on your relay and exclude certain users' follows from your web-of-trust if you notice that they have been duped into following bots.
UTXO calls this last feature the "Retard List." My retard list keeps growing...

2025-04-05 02:04:14

- reply

Pointers for running your own WoT relay?

2025-04-05 02:01:12

- reply

NIP-17?

2025-04-05 01:47:24

Things you learn from running a Web-of-Trust relay:
Trust no one.

2025-04-05 01:38:09

- reply

With some notable exceptions, but yes, in general we have a great community here.

2025-04-05 00:25:24

- reply

I know my personal repository of Nostr apps and tools is WAY out of date. 😂

2025-04-04 21:53:50

- reply

I dunno. There's still plenty happening. A lot of projects have died, for sure, but they either weren't interesting enough to the community to keep going, the devs behind them lost interest or don't have time to work on side-projects, or they just couldn't find a way to become sustainable.
I don't know about others, but I haven't noticed a drop in folks engaging with me, and I am engaging more than ever on here. I have definitely seen others commenting on the feeling of less interaction happening, but that hasn't been my experience.

2025-04-04 21:07:53

- reply

https://fountain.fm/show/vnmoRQQ50siLFRE8k061

2025-04-04 20:44:50

- reply

LOL! @npub1syj…f6wl it looks like Jumble is automatically adding "nostr:" in front of "npub." It should probably only do this for a full and valid "npub" string.

2025-04-04 20:15:57

- reply

Using npub.world to see their "reputable followers" can be very enlightening, too...
https://npub1kun5628raxpm7usdkj62z2337hr77f3ryrg9cf0vjpyf4jvk9r9smv3lhe.blossom.band/ceb5adc47457988d865b15a2926b1631cbbfbdfb7e0155f0a93c884c7d25f137.jpg

2025-04-04 20:12:05

- reply

It should also be noted that WoT scores on #Coracle are completely individual. So, while this user may have a score of -14 for you, they have a -24 for me, because more of my follows have muted them.

2025-04-04 20:07:28

- reply

Some have. I highly recommend #Coracle for that feature in particular.
You can also get this feature on all Nostr clients by only reading from your own Web-of-Trust relay that aggregates notes from nostr:npubs within your web-of-trust. That is a bit more involved to set up, though.

2025-04-04 19:39:48

- reply

That's something different. A shitcoin to be precise.
Check out Cashu protocol. A great wallet for it on Android is @nprofile…vavr and one on iOS is Macadamia.

2025-04-04 19:26:37

- reply

Here's a reply I made regarding why follower counts are always wrong and they always will be:
#nevent1q…esml

2025-04-04 19:20:02

- reply

Think of it like the relationship between gold and the dollar, back when banks would issue dollars as a "receipt" of the gold that was on deposit with the bank, and anyone carrying that receipt could turn it back into the bank to get the gold out.
eCash works in a similar way. A mint receives real sats as a deposit, typically via lightning, but it could be on-chain too, and they issue/mint eCash tokens to the one who deposited the sats. Just like USD, they can transact with anyone willing to accept the eCash as payment directly and privately, even offline, simply by transferring the tokens to that person's eCash wallet, which can hold tokens from any mint.
The big difference with eCash compared to the gold/USD reserve relationship of the past is, if someone DOESN'T want to receive your eCash as payment, you can easily have the mint that gave you your tokens send them sats via Lightning instead by turning your tokens back in with the mint to be burned.
Obviously, this means you are putting a lot of trust in the mint to honor your request to redeem their tokens back into sats when you want to transfer them out of the mint. It is a custodial relationship where you are holding IOUs that are only as good as the mint is honest. Great for small amounts, but I wouldn't trust it with anything more than I would keep as cash in my physical wallet.

2025-04-04 18:42:01

- reply

Sounds like @npub1v0l…qj49's Freeflow, but built on BlueSky's ATProtocol instead of something that is actually decentralized.

2025-04-04 18:12:45

- reply

Negative.

2025-04-04 18:08:03

- reply

You're not thinking too far ahead: https://www.solosatoshi.com/product/solarbit/
There are currently only three reasons not to generate block templates yourself:
1. You don't run your own node and don't want to start.
2. You don't like OCEAN for some reason, such as preferring FPPS payouts rather than only getting paid when the pool finds a block.
3. You don't want to run Knots as your Bitcoin node implementation.

2025-04-04 17:22:28

- reply

I'd say D, which means I am probably actually at B.

2025-04-04 17:04:21

- reply

Yeah, Phoenix and Breez both handle a lot in the background for you. However, because they do this, you can end up with an unexpectedly high fee when you are receiving a transaction and it exceeds the available inbound liquidity. That can be a bad experience for a non-technical person who doesn't understand why the fee is higher and how they could have avoided it.
For instance, because I knew that Phoenix was going to be creating an actual Lightning channel when I first deposited into it, I sent WAY more sats than I actually wanted to have in the wallet (5 million), so that Phoenix would open a really big channel. Then I swapped them back to on-chain via Boltz.exchange, so I wouldn't have such a large balance in a spending wallet. Leaving me with plenty of inbound liquidity in my Phoenix channel.
No non-technical person who doesn't understand how Lightning works is going to know that they should do this. They will send themselves 100k sats or so, and Phoenix will give them a channel of a few hundred thousand sats, and as they use the wallet more and more, they will be comfortable with keeping a higher balance on it, only to get randomly slapped with a higher fee because they ran out of inbound liquidity in their channel.
Breez's new Misty Breez wallet is looking really interesting for non-technical folks to have a better trust trade-off than going with a custodian, though. It still requires the responsibility of holding your private key, but that should be one of the first things a new Bitcoiner learns anyway. For my kids I will stick with hosting their Lightning wallets for them, but once they care enough to hold their own keys, I might be having them learn on Misty Breez.
As for how to find other nodes to connect to, I have seven channels. Five of them are with other Bitcoiners I know and can reach out to personally if there is ever any issue. They also reach out to me and ask what's up when my node is down. The other two channels that aren't with Bitcoiners I know are with nodes that are operated by services I use personally; namely ACINQ (Phoenix) and Boltz.exchange. As such, I have never had need to purchase a channel from a liquidity provider.
The best channel partners are Bitcoiners you know and can contact directly to troubleshoot issues with your channel.

2025-04-04 15:23:20

- reply

I am going to flip that question on its head a bit. What is the incentive NOT to make your own blocks? If you already run a node that has its own mempool, why would you want to be beholden to someone else dictating what your miner is hashing? What do you get out of that that you would not get if you created your own block templates?
In my mind, the only reason not to create your own block templates is if you aren't running a node. And then question is, why the heck aren't you running a node?
And then, yes. OCEAN gives a discount on the pool fee for those who use DATUM to create their own templates, and you pay zero pool fee whatsoever if you are lottery mining using DATUM. So the incentive is you get paid more in either scenario. Assuming you are fortunate enough to get paid at all in the lottery mining option.

2025-04-04 05:41:45

- reply

In the scheme of things, DATUM is quite new. Only been around since what, September of last year? Still a baby.
Usually it takes someone who is using a node implementation, who has some dev skill, and who wants to use the application himself to package an app for that platform. It's usually not the devs behind the node implementation itself who take it on.
The less popular the node implementation, the less likely the person with both the skill and the interest in doing the work exists.

2025-04-04 04:30:28

- reply

You are too kind @nprofile…esx4 ! I just have to give back what I have received from others. Paying it forward.

2025-04-04 04:24:31

- reply

The stratum address on Umbrel would be "stratum+tcp://[YourUmbrelLocalIP]:[DATUM's Port]"
The port on Start9 is 23335, but not sure what port it uses on Umbrel.

2025-04-04 04:06:32

- reply

If you also run your own Bitcoin node, why not forego a pool altogether and run DATUM?

2025-04-04 03:54:46

- reply

If you are lottery mining using DATUM, you aren't connecting to anyone else, just your own stratum server hosted on your node via DATUM. Your node, of course, is connected to its peers on the Bitcoin network, and they gossip about what transactions are waiting to be added to blocks. That's how your node knows what transactions are waiting, even if they were submitted by someone half the world away.
Now, the downside of this, as with any lottery mining, is that you don't get anything if your Bitaxe never finds a block. I am not someone who can crunch the numbers on that likelihood, but I seem to remember someone saying that if all you have is a BitAxe, you will find a block on average once every 30,000 years at the current network difficulty, and you are just praying that you will get exceptionally lucky and have it happen in the portion of that 30,000 years that overlaps with your lifespan. 😂
Another way of saying it is, if you have 30,000 BitAxes, then your chances are pretty good that one of them will find a block each year. You might go a few years without any of them finding a block, while you find two or three blocks another year, but it will average out to about 1 block a year.
When you are connecting to OCEAN through DATUM, you are no longer lottery mining. The downside of this is, if you find a block, you have to share the rewards with all the other miners in the pool. But the upside is, you will get rewards for your small contribution to trying to find a block, even when it is someone else in the pool who found it. And because OCEAN has Lightning payouts, you can get paid directly to your Lightning wallet via a BOLT-12 invoice each and every time the pool finds a block, with no need to wait to build up enough sats owed to you for an on-chain UTXO.
So it's the difference between having a chance at a MASSIVE payout, that probably will never come, vs getting exceptionally small payouts virtually every day.
Either way, though, if you are a noderunner already, and you want to do some home-mining, I don't see any good reason not to use DATUM and either lottery mine on your own, or connect to OCEAN for pooled mining.

2025-04-04 03:32:18

- reply

The only thing you don't control when using DATUM with OCEAN is the payout split. OCEAN provides that to your DATUM server, and DATUM includes it in the block template. But when you are lottery mining with DATUM and not connecting to OCEAN at all, then you are in control of absolutely every aspect of it. What transactions are in the block, where the reward goes, broadcasting the block to the network if you find one. It's all you, baby!

2025-04-04 03:27:43

- reply

Nailed it!

2025-04-03 23:09:13

- reply

Thank you! I appreciate that encouragement!
Let me see if I can answer the particular questions you had, and then I will think about writing something long-form on the subject.
There are a few different types of pools now. Your bog-standard mining pool, like Braiins, Luxor, or F2Pool, allow individual miners to point their hashrate at the pool's stratum server, so that the pool is determining which transactions are included in the blocks found by any miner in the pool. Additionally, they don't pay the miners in the pool directly from the block rewards. Instead, the block reward goes 100% to the pool, and they credit each miner's account held at the pool based on the proportion of hashrate they are contributing to the effort of finding a block.
Worse than that, though, a handful of these pool operators aren't even constructing the block templates they send to miners on their pool. Instead, they are just using the same block template as AntPool. Meaning that AntPool has an even more outsized influence on which transactions make it into blocks than their pool's hashrate alone suggests.
What is more, most of them use the FPPS payout method, which means they credit their miners accounts on a set schedule, regardless of whether the pool finds a block. This means they need to have plenty of Bitcoin set aside for times when they get unlucky and the pool doesn't find any blocks, but they still need to credit the miners.
There are other mining pools which only credit the miners' accounts when the pool actually finds a block, but those are becoming few and far between these days.
These pools also typically have a minimum amount you need to accumulate in your account (e.g. at least 100k sats) with the pool before they will allow you to withdraw. The exception would be Braiins, since you can auto-withdraw via Lightning even very small amounts. This can create pool lock-in, since miners won't want to switch pools if they still have a ways to go before they earn enough sats to withdraw.
Next we have the lottery pools, like Public Pool or Solo CKPool. They are similar to the other pools previously mentioned in that you point your miner's hashrate at THEIR stratum server, so they are controlling which transactions end up in a block by creating the block template for you. However, if your miner finds the block, you will be the only one on the pool to receive the block reward (minus pool fees). Conversely, if someone else on the pool finds a block, you get nothing.
Then there's OCEAN. When they started, the only option was to point your miner's hashrate at their stratum server, so they 100% dictated which transactions made it into blocks, just like all the other pools, but what differentiated them was that the block reward didn't go to the pool to then be credited to miners' accounts. Instead, miners with enough hashrate were paid DIRECTLY within the block. Those without enough hashrate to justify the creation of a UTXO still had to wait until they accumulated enough to get a payout, though.
Then OCEAN allowed miners to pick between a few different block templates, based on how strictly they wanted to filter out spam from any block they found, or even choose not to filter at all. This in itself had never been done before by a pool that I am aware of.
They also added the option to receive payouts via Lightning. So now the bigger miners could receive on-chain payouts directly from the block reward, and the small fries, like me, could get paid immediately via Lightning, even if it was just 40 sats at a time.
That still wasn't good enough for OCEAN, though. They didn't want to be in control of which transactions make it into a block AT ALL. Not even by offering a few different options to choose from. They wanted each miner to be able to create their own block templates using their own node's mempool data. This was the promise made to us by those developing Stratum V2, but it was taking a while for that protocol to be ready, so OCEAN created DATUM. Now the only thing that OCEAN has to do is send the miners the reward split for them to include in their blocks, and if they find a block, they don't have to send anything to the pool. They just use their node to broadcast the block they found, with the reward split to the other OCEAN miners, to the rest of the network directly.
Finally, DATUM has enabled those who want to lottery mine to cut out the need for connecting to a pool at all. Instead, they just connect to their DATUM server, which gets transaction data from their mempool to include in the block, and sends the block reward directly to their Bitcoin address, should they find a block. Of course, because they are not contributing to the efforts of a pool, and are giving themselves the full reward, they also get no reward at all in the much greater likelihood that they never find a block. But then, that's why it's called lottery mining, right?
There's also a new pool on the scene, finally using Stratum V2 to allow miners to construct their own block templates (I think), called DMND pool. Going to have to do some research to see exactly how this compares to the way DATUM works on OCEAN.
As far as your second question, the difficulty your miner is capable of achieving and its hashrate are not connected to one another. A 20TH machine will find very low difficulty hashes and very high difficulty hashes, and if they find a high enough difficulty hash before any other miner does, they find a block. Same with a 1TH BitAxe. Some pools just won't give you any credit for hashes below a certain difficulty. The more hashrate you have, the more hashes you will find that meet that requirement, but it should still be pretty proportional, so a 20TH machine will find 20x the hashes that meet the minimum difficulty as a 1TH BitAxe.
The only viable pools to use a BitAxe with, though, are going to be ones that pay out via Lightning, or lottery pools, where you only get paid if your BitAxe happens to find a block. That is due to the amount of sats you need to earn to meet minimum withdrawal restrictions for on-chain payouts, though, and nothing to do with the BitAxe's ability to generate hashes with sufficient difficulty.
Now that I have answered both those questions, all of the above could probably just be a long-form note. 😂

2025-04-03 22:01:48

Can anyone point me to a good comparison between the way DATUM works on @npub1qtv…7dze vs how Stratum V2 works on DMND pool?
I am getting the impression that the pool still has some control over which transactions are in a block in Stratum V2, and instead of the miner who finds the block submitting it directly to the network, they first submit it to the pool, who then submits it to the network. Is that correct?
#asknostr

2025-04-03 17:40:18

- reply

I am asking because I want clarity of language, and because I may be mistaken about how things work, so I am hoping for clarity if I am.
It seems to me that if we are going to call Liquid self-custody, then we must do the same with fedimints, and perhaps with all eCash, especially given @npub1ey6…szvp's response here:
#nevent1q…lswx
If that's the case, though, we should always be careful to specify that it is self-custody of something other than Bitcoin. It is self-custody Liquid, or self-custody eCash, etc. I can definitely live with that framing. No one can take the token you hold the keys to from you, but they could still rug the underlying Bitcoin, and the user should be very aware of that.

2025-04-03 16:56:13

- reply

Yeah... that's gotta be something about how they handle changes to the display name. They are obviously seeing your kind 0 note and updating other profile info accordingly, but they are not updating the display name that is contained in THE VERY SAME NOTE!
@npub16c0…6nvr, @npub1zga…ppvc, and @npub1ye5…knpr can you shed some light on this?
I can remember back in the day when @npub1m4n…c2jl was always changing her display name and profile picture, which was confusing a lot of users because they didn't recognize her and wondered why this person they hadn't followed was showing up in their feed. Maybe changing display name is not respected in these clients to help prevent something similar?

2025-04-03 15:40:44

- reply

I completely forgot this tool exists! Thank you!

2025-04-03 05:16:27

- reply

While I can pronanly take his reaction as a "yes," I also confirmed by going into my Datum settings, and I can disconnect from the pool entirely to both solo AND lottery mine, should I choose to.

2025-04-02 22:47:43

- reply

It was a question, not an accusation.

2025-04-02 22:46:18

- reply

Or should we get rid of zaps, because scammers can use them to extract value from the gullible?

2025-04-02 22:36:51

- reply

Oh for sure! We see the same sort of scammers and grifters in other areas of life, as well.
"A fool and his money are soon parted."
But in the long run, those providing genuine value receive more positive reinforcement. And there's not really a way to prevent people from being gullible, as we have seen repeat itself over and over in cRyPtO.

2025-04-02 22:18:42

- reply

Ser, have you heard of zaps?

2025-04-02 22:06:31

- reply

I am not sure it is possible to gamify the best parts of human nature. Those require intentionality, discipline, self-control, and critical thinking, all of which are antithetical to the "turn your brain off and do the things the system gives you a dopamine hit to reward you for doing."

2025-04-02 21:53:05

- reply

I can only speak from my own experience here, but I transact a ton in Bitcoin... on Lightning. Not just zaps, but purchases.
I have to do an on-chain transaction to throw sats into cold-storage a few times a year, or open a new Lightning channel once or twice a year, but that's all, and I am sure I'm not alone in that.
Also, if we look at mempool history, the last couple years of sustained high volume of transactions is an anomaly. Most of the time, transaction volume is low, except during times of high price volatility. Times when people are either moving their coins onto exchanges to sell them, or scooping up cheap sats and sending them to cold-storage.
That makes me think this is just the calm before another such storm.

2025-04-02 21:18:58

- reply

It's not a big deal on Amethyst, but most other clients...

2025-04-02 20:19:39

- reply

The concern is not so much with you being able to upload the media to your server, since that only needs to happen one time for each piece of media, and your personal patience is the only thing affected by it, but rather on the ability of others to view your media.

2025-04-02 19:18:53

A Blossom implementation packaged for @npub1agh…mhct, or for @npub126n…e9ll after the next major OS update, would be INCREDIBLE!
#nevent1q…4zh8

2025-04-02 19:14:23

- reply

@npub1yau…vjmf is working on an iOS signer so you don't have to anymore, but until then there are no options except to paste in your nsec and hope for the best.
On some web apps you have the option to use nsec.app for remote signing, but the UX is pretty rough...

2025-04-02 19:10:35

- reply

How many sats do you need to build up before the pool lets you withdraw, or is it lottery mining, where you would get the full block reward IF you find a block, but nothing at all if you don't?

2025-04-02 18:56:30

- reply

Nostr doesn't have any images on it, so it can't be slow to load them. Nostr only has notes.
Images, videos, and other media must be hosted somewhere else, like a Blossom servers or nostr.build, or anywhere else that will give you a URL to access the media after you upload it.
How fast images load will depend on many factors, including the bandwidth of your media host, how the Nostr app you are using fetches that media (for instance if it uses a proxy in-between), and your own internet connection, etc.

2025-04-02 17:32:09

- reply

First, everything is tradeoffs. Know that going in.
eCash is really just custodial Lightning with some extra steps, but those extra steps provide some distinct advantages.
In normal custodial Lightning, your custodian has the actual ownership of the sats in their Lightning channels, and they internally keep track of how many of those sats belong to you on their server. You are trusting that they are keeping accurate record of how many sats are owed to you, and not spending or rehypothecating them. They can rug you at any time.
With eCash, your custodian is still the actual owner of the sats in their Lightning channels. They keep track of the total amount of eCash tokens they have issued, but they keep no track of your balance. Your wallet does that using the tokens that it stores as files, either on your device or on a server you control, or on a relay with the tokens locked to your npub. This means you are responsible for keeping track of your tokens, rather than your custodian keeping track of your balance. Lose your tokens and your custodian will not be able to recover them for you since they keep no track of your balance.
This enables eCash to be far more private than custodial Lightning, and the tokens can be transferred to anyone else who is willing to accept them, even offline. And then, when the bearer of the tokens wants to transfer funds out of that custodian, they turn the tokens in and the custodian SHOULD give them sats in return.
However, the custodian can still rug you. You still have to trust that the custodian hasn't spent or rehypothecated the sats your tokens represent.
In self-custody Lightning, you have actual ownership of the sats in your Lightning channels. No one can spend those sats but you. However, it is harder to transact privately with self-custody Lightning, and there is no way to transact offline. Additionally, you bear the responsibility of managing your Lightning channels and making sure you have enough liquidity in the direction you need in order to transact.

2025-04-02 16:27:49

- reply

Not sure. I have only ever used it with one service and I logged in using my Phoenix wallet, ehich is technically a node, so...

2025-04-02 16:24:18

- reply

Alby extension can do Nostr login even more easily than Lightning login, if the latter is restricted to only Alby Hub users. Then anyone who wants to post a message could simply be presented an invoice for 10 sats that they can pay with their Alby extension, too, regardless of what wallet they connected to it.

2025-04-02 04:39:43

- reply

Definitely up for discussing your ideas any time!

2025-04-02 00:25:48

- reply

I believe that if you use Shopstr you will, by default, also have your wares listed on #Amethyst's marketplace. Another option is @npub1mar…p7hd.

2025-04-01 23:49:43

- reply

Ah, I see it. Interesting that Amethyst interpreted that as a "Don't parse this."

2025-04-01 23:44:10

- reply

So, was it the client making the tag, or the client parsing it at fault? Most work so long as the tag is formatted as `nostr:npub1...` when it is posted.

2025-04-01 23:38:12

Now that's service!
#nevent1q…06he

2025-04-01 23:32:07

- reply

The protocol itself has some interesting aspects to it, but it's not being utilized in a decentralized way like Nostr is. It is theoretically possible for it to be decentralized, but no one is actually putting in the work to make it so.
It would be like if Nostr only really had one client that everyone used, and one relay that was run by that client's dev team.

2025-04-01 22:38:07

- reply

@npub10pe…n34f is actively supporting Nostr development. We could definitely stand to have more similar non-profits that support Nostr devs. However, grants are not a sustainable way to keep Nostr going.
The way non-Nostr apps generally make money is via advertising. Most around here want to avoid that model like the plague because, while easy to make profitable, it creates perverse incentives for developers to harvest user data and make their apps addictive to keep people doom-scrolling. I am very interested to see how @npub17vs…66ne may bring us an advertising model that bucks this trend. We'll see.
Another means of monetizing for client devs is paid subscriptions for premium features. The tough part about this one is, a lot of those "premium" features are often available for free on other clients, so you end up getting undercut by devs willing to provide the same value for free. Nevertheless, there are clients that are trying to make it work, including #Damus and #Primal.
Value-4-Value is really popular here on Nostr, so it shouldn't be surprising to see that there are devs testing out if they can support their work in this way. #Amethyst, for example, displays a donation card at the top of your Notifications each time you install a new version of the app. It also displays the profile pictures of all the folks who contributed to that version of the app. The hope is that users will choose to support the clients they use voluntarily. #Coracle does something similar, very occasionally showing an opportunity to donate to the continued development of the client in the user's main feed.
Any app, Nostr or otherwise, that is on the @npub10r8…t2p8 has the opportunity to receive V4V zaps each time they release a new version of their app.
An interesting method of having ongoing passive income for your client that I have seen a couple of them implement is the option to have a percentage of your zaps go to the client dev as a zap split. Say you regularly zap 21 sats, you can have 10% go to Coracle each time you use that client to zap someone. The user you zapped still receives 21 sats, but you pay an additional 2 sats to Coracle, for a total of 23 plus Lightning fees. You can also adjust this higher if you want to give the dev more support. Obviously, this is barely anything if you aren't a prolific zapper, but it can add up quickly if you zap a lot.
A couple other client devs are building their clients with the ability to have a custom instance, such as #Ditto and #Flotilla. There is an opportunity for monetization there for offering to host that instance for those who don't want to or can't host it themselves, but still want a custom version for their community.
The same could be done by relay devs. They could offer hosting services for their relay implementations, similar to what @npub10np…tl5h has done with relay.tools, for those who want to have their own relay, but don't know how to set one up to host themselves, or don't want to host it on their own device for privacy reasons. They could also provide easy means of exposing a self-hosted relay to clearnet for those who don't own a domain and charge for that service.
Clients could also charge a small amount for a NIP-05 service and the ability to turn it into your Lightning address via Nostr Wallet Connect.
So yes, there are a ton of ideas for monetization out there, and many more I haven't listed, I am sure. Moreover, client devs are not sleeping on them. Many of them have implemented a means of receiving income for their work in some form or another, and some of them are using more than one. Therefore, I think it is a mischaracterization to suggest they aren't taking this challenge head on. Many most certainly are testing out various ideas to monetize their work, including simply trying to build apps that folks would be happy to pay for, or at minimum donate toward.

2025-04-01 21:24:51

- reply

If that is the case, then generating them offline is superfluous. The browser extension or mobile signer will be online and a possible means of the key leaking. You may as well just use the browser extension or mobile signer itself for generating the keys without worrying about being offline when you do it. Your private key is just as vulnerable being held in an application on a device connected to the internet as it is being generated by an application on a device connected to the internet.

2025-04-01 21:20:23

- reply

How are you planning to log into Nostr apps?

2025-04-01 20:39:43

- reply

Unless you are making the app yourself, ANY app is 3rd party.

2025-04-01 20:37:48

- reply

How would keys be created without using an application? Rolling them by hand with dice?

2025-04-01 19:59:59

- reply

I am not sure I entirely agree with that, but I see your point. Not everything needs to be motivated by profit to survive. A lot of devs are scratching their own itch with the things they build on Nostr, so they are happy to plug away at it in their spare time, because they get value out of what they build just as much as we do as users.
Also, profits can easily corrupt products, depending on the business model, because they can create bad incentives. I think Primal is an example of this. They clearly want to be profitable, and it has led them to make some choices in how their product works that are distinctly antithetical to the Nostr ethos.
That said, I think the clients and relay implementations that are most polished and user-friendly will likely be built by those highly motivated to be profitable. They just need to be very intentional about finding ways to make a profit that don't skew their incentives. What exactly will properly compensate devs for their work without creating bad incentives around how they iterate on what they are building? That's a really tough nut to crack.
I would love to hear your suggestions in that area, particularly around how client devs ought to monetize, and how relay implementation devs should monetize. Those who run relays can obviously charge for write and/or read access to their relay. Those who host media can do the same for their Blossom server. Heck, @npub1utx…50e8 built Aegis specifically for that purpose. But how client and relay devs get paid for their work is a much harder problem to solve.

2025-04-01 17:23:31

- reply

I think the current total dollar value of all assets in the world is $915 trillion. That being the case, the theoretical maximum purchasing power of 1 Bitcoin would be about $61 million in TODAY's dollars. As the dollar's purchasing power declines over time, that number could go up drastically, but it would still be purchasing about the same amount of goods and services.

2025-04-01 17:06:33

- reply

All sorts of different ways of structuring and displaying communication are possible on Nostr. It's just a question of whether there is a note kind already defined that would be appropriate for it, or if a new kind must be defined. Existing kinds may not support the tags and content fields you need for what you want to build, but they have the advantage that users are already posting those kinds to relays, so your new app will immediately have content to display. Defining a new kind has the advantage of flexibility in determining what sort of content and tags must or may be included in that kind, but has the downside that no one is yet using it and relays may reject it until relay implementations have been updated to support it.

2025-03-31 22:02:42

- reply

It's a made-up word from an acronym. There is no "right" way to say it.
But if there was a right way, it would be NAW-ster, to go with "Nostrich." 😉

2025-03-31 21:58:22

- reply

Very grateful nothing happened while she was driving it! $1,000 is nothing compared to possible catastrophe.

2025-03-31 21:56:48

- reply

It's something to do with the steering assembly. She's apparently quite fortunate that the wheel didn't come off on her.

2025-03-31 20:32:34

- reply

The only issue I have with some many of the current methods of combating bots and spam is that there isn't any way to differentiate a brand new user from a bot, so it adversely affects new users, too.
It's not terribly difficult to break through this. You just have to know someone who is on Nostr already and ask them to follow you via some other means of communicating with them. But if you don't know that you need to do this in order to bootstrap into not being considered a bot by everyone's WoT relays and Pagerang filters, then you'll just be shouting into the void and wondering why no one ever sees it.

2025-03-31 20:09:53

- reply

Not a podcast, but I do have a website where I have posted a couple full length reviews that should offer some insight into how things work, including a review of Primal. I have also started a sub-series of articles explaining some of this stuff in plain language.
You can find it at https://www.nostr-reviews.com

2025-03-31 19:55:38

- reply

Can relate.

2025-03-31 19:45:48

- reply

"It's a great time to consolidate UTXOs!"
*Posts consolidation transaction with 150x higher fee than needed*
"No! Not like that! The whole point was to take advantage of the low fee rate!"

2025-03-31 19:42:57

The woes of not owning your identity or your ability to speak without permission.
#nevent1q…2ve0

2025-03-31 19:30:13

- reply

I doubt many use this feature on a regular basis. Remember, most of what you post on Nostr is entirely public, so you are not seeing anything the user should not expect you to be able to see.

2025-03-31 19:23:29

- reply

Which node implementation did you go with? Some are meant to be a bit more user-friendly, but managing Lightning node liquidity is definitely a bit more than most folks want mess with.

2025-03-31 17:50:17

- reply

Nostr doesn't require any blockchain, so no.

2025-03-31 16:01:05

- reply

Yeah, for things like nostr.build, something that ONLY does log-in is fine, since signing isn't needed for anything else within their service. However, NIP-46 signing can handle just logging in if that is all you need, as well.
My point is, why use proposed NIP-97 that never went anywhere and can only be used to log in, without doing anything else, when we have NIP-46 that CAN be used for just logging in, if that is all you need, but can also be used for further signing?
If the answer is that iOS won't be able to do NIP-46 signing, then that might make some sense.

2025-03-31 15:24:47

- reply

Yes, relay.nsec.app is the default for handling bunker/remote signing, but it can be configured to use a relay you choose. Not all relays accept the signing event types that are used for this signing method, though.
I go over both signing methods Amber uses in my full review of Amber at https://www.nostr-reviews.com.

2025-03-31 04:37:36

- reply

How are you connected? Native Android signing, or bunker signing?

2025-03-31 04:16:40

- reply

Ok, you have my interest piqued.
I will readily admit that follow lists is all I am really familiar with from legacy platforms. Maybe I just don't know any better because of that. I am just not understanding how you could replace follow lists with relays.
Sure, you can have a relay that only certain npubs are whitelisted to be able to post to, but you'll still only see posts from them on that relay if they add it to their write relays. That is unless you have the relay aggregate their notes from other public relays... And then have the ability to qyery your relay for a subset of the notes you want to see...
Doable, I suppose, but it's a big ask for most folks to run and manage their own relay without them being made WAY more user friendly.

2025-03-31 03:15:14

- reply

It would take about 6,000,000 Bitaxes to equal just OCEAN's hashrate... It's probably more likely that someone would randomly guess the seed words to your cold-storage wallet than for a single Bitaxe to mine two consecutive blocks.

2025-03-31 02:54:31

- reply

Well, the trouble with anything on mobile is the OS killing the app when it is in the background. We can get around that with persistent notifications on Android, but maybe that's not an option on iOS?

2025-03-30 23:11:26

- reply

Why this over just making every client a NIP-46 signer that can not only log you into other services, but also sign events?
This option seems like it would work for log in, but not for anything that actually requires signing of events.
Consider how most users onboard to Nostr. They download a client they heard about like Primal, Amethyst, or Damus, and they generate their keys in that client. So that first client is going to have their private key unless they have a friend who helped them get set up through a dedicated signer app like Amber. If that's the case, then those "flagship" clients ought to be able to serve as remote signers, similar to how Gossip on desktop can be a remote signer, allowing users to log in and to sign events from the client where they generated their keys.
NIP-97 seems to just allow the first part, which is unnecessarily limiting when we already have NIP-46. We would just need a more smooth way for a website to request a connection string from the remote signer app/Nostr client.

2025-03-30 21:55:27

- reply

Very well could be. Primal's wallet is provided by Strike, so you won't be able to use it if Strike isn't available in your country.

2025-03-30 14:48:56

- reply

That's because Amethyst is doing the work of searching for all of the follow lists on all of the relays that contain that user's npub, excluding duplicates, and tallying them up in real time. By contrast, a client like Primal pulls all notes it can find from other relays into their caching relay on an ongoing basis, and so it can have a pre-calculated follow count for each user.
That is also the reason why Amethyst can take some time to load profile data. It has to actually fetch it from whichever relays that user writes to. Meanwhile, Primal only has to get it from their caching relay that has already fetched the data from everyone's write relays.

2025-03-30 14:40:27

- reply

Primal doesn't connect to relays to read from them, only to write to them, but I have noticed that it loses connection and won't post anything after a while, and I have to refresh the page.
For reading notes, Primal only connects to their own caching relay, which I have never noticed it having trouble staying connected to.
What a lot of users often perceive as Primal being really slow to load is when they are using custom DVM feeds, such as "Popular from Npubs You Follow." These feeds are not served by Primal at all. Instead, Primal requests a list of notes from the DVM, waits for the DVM to sent it over, and finally fetches them from their caching relay. The wait time from that DVM is often the slow part.
Videos can be a whole other issue unrelated to clients at all. Remember, this is a decentralized protocol, not a centralized platform. On platforms like Facebook or YouTube, they can ensure that optimization is done on the videos uploaded to ensure quick loading.
On Nostr, users can upload videos wherever they want. Directly through some clients that may or may not optimize the video for web, through a hosting service, or even self-hosted.
It's pretty easy to load videos quickly when you have control over ensuring they have been optimized and you only have to fetch them from your own servers. Nostr clients have neither of those luxuries.