Primal isn't bad, but Longform is clean and uses standard 30024 for drafts.

Longform._ is truly a pleasure to use for writing and publishing long-form notes.

Great job with this client nostr:npub15ypxpg429uyjmp0zczuza902chuvvr4pn35wfzv8rx6cej4z8clq6jmpcx! I am very happy to support your work!

nostr:nevent1qvzqqqqqqypzpggzvz325tcf9kz79s9c9627430ccc82r8rgujycwxd43n92y037qyvhwumn8ghj7am0wshxyunfva58gcn0d36zumn9wshsqgpc55mcztfgam4d80md352dljaunzge29cq07fymlcp94n0f43zgun9mr75

This!

If Bitcoin could exclude state actors from owning it, it wouldn't be good money, any more than if it could exclude criminals from using it. Heck, most of the time the two are synonymous.

nostr:nevent1qqs96mv6tzfwmy323gcufmnqkzsu9pm42l5sayayn22hegvmgrdzq4gpzamhxue69uhhyetvv9ujumn0wd68ytnzv9hxgtczyzkuznar44vss4ka3wqgzhfk0a7puee445q0mx9gd5qzl05lk567zqcyqqqqqqgqg70h6

Most free media hosting, especially those powered by the Blossom protocol, have a 100MB per upload limit.

Going to need to do some compression before uploading.

Well, that works. It's ugly though. Close to unreadable. Doesn't preserve any formatting or load any images.

Looks like anyone who has an npub.pro page can have that feed in an RSS reader and it looks decent. Just doesn't know what to do with Nostr URIs.

I know there are tools for turning RSS feeds into #Nostr npubs, so you can follow them in your favorite Nostr client. Are their tools for going the other direction, too?

Say I want to add nostr:npub1m4ny6hjqzepn4rxknuq94c2gpqzr29ufkkw7ttcxyak7v43n6vvsajc2jl 's long-form notes to my favorite RSS reader? Is there a way to convert her kind 30023 note feed into an RSS feed that any RSS reader can display?

I suppose the best option would be to just use a Nostr compatible RSS reader like Narr, since regular RSS readers wouldn't know what to do with any Nostr URIs within the articles.

#asknostr

GM nostr:npub1dergggklka99wwrs92yz8wdjs952h2ux2ha2ed598ngwu9w7a6fsh9xzpc

Y'all are doing great work!

I probably don't use Maple enough to justify the cost, but went ahead and subscribed anyway, because I believe in what y'all are doing. You'll have all the things eventually.

Yes, it most definitely can.

That said, I think Start9 is better used for Bitcoin and Bitcoin only apps, and if you want to have a simple home-server to replace Google Drive and iCloud, go with an Umbrel. There are a TON more apps available for Umbrel, and you will have a much easier time connecting to it remotely, since each service on Umbrel has its own port. Tailscale is also available for Umbrel, but not for Start9, yet.

Start9 will eventually be updating the OS to have more remote connection options, but I have personally been waiting for that promised update for 2 years now, and no ETA when it will be available. Without that update, your only real way to connect to most services remotely is going to be via Tor, which is significantly slower.

You don't hear much talk about it for the same reason that you don't hear much talk about safely storing your Lightning wallet's private key offline. Lightning keys need to be stored on an always online device, because they are used to update the state of your Lightning channel(s). Your key is used both for sending and receiving.

Nostr keys are similar. As Ryan mentioned earlier, your Nostr keys are used to sign for literally everything you do on Nostr, so you can't really keep them offline, or you'll constantly have to be digging out your signing device for every reaction, zap, comment, and post you make.

There have been some attempts to come up with a key delegation standard, which would allow you to have a master key that is kept offline, and it can sign to delegate a child key to have the authority to sign on its behalf, and that child key would be what is used regularly to sign for everything you do on Nostr. Meanwhile, the master key would be kept in an offline signing device and only used if the current child key was compromised and it was needed to sign to revoke that key's authority and delegate signing authority to another child key.

Unfortunately, it turns out that this adds a TON of complexity that every Nostr client would have to account for, and would break every client that currently exists until they could figure out how to implement it.

It makes sense to me, but I also don't like it and don't think it would make sense to the average user.

I would hide these settings in an advanced option where users like myself who know what they are doing can still go to change them if we want.

When it comes to their descriptions, you could have a little (i) icon next to the relay category name and then display a toast message when it is hovered over or clicked on with a bit more detailed description of what that category of relays is for and whether it is for noStrudel only, or will update relay lists that may be used by other clients as well. That would keep the interface looking pretty clean, but still allow the user to access the information they need.

On these type of relay lists I go back and forth between whether the description of what they are for should be as easy to understand as possible, or filled with jargon so that only those who actually understand what they are doing will mess with it. 😂

Amber does 2 things with relay connections:

1. It fetches your profile information so it can show your display name and profile picture to help you distinguish whick of your npubs you are selecting to sign for.

2. It sends and receives NIP-46 remote signing messages back and forth with clients you logged into using NIP-46. The background relay connections are required for this signing method.

If you don't use NIP-46 for logging into and signing requests for any clients, I'd imagine you can simply remove all of your active relays, but if you use NIP-46 remote signing, you will need to keep them connected so Amber will see when any new signimg requests come in.

nostr:nprofile1qqs827g8dkd07zjvlhh60csytujgd3l9mz7x807xk3fewge7rwlukxgpz9mhxue69uhkummnw3ezumrpdejz772u5wm is the one who would be able to confirm if there is a way to disable all relay connections in Amber, though.

nostr:nprofile1qqsth7fr42fyvpjl3rzqclvm7cwves8l8l8lqedgevhlfnamvgyg78spz4mhxue69uhhyetvv9ujuerpd46hxtnfduhszrnhwden5te0dehhxtnvdakz7qghwaehxw309aex2mrp0yhxummnw3ezucnpdejz7qnse3k is a better optiin for web apps on mobile than using PWAs.

Signing into PWAs using Amber generally requires NIP-46 signing, instead of NIP-55, which is used for native apps like Amethyst. I have always found NIP-46 signing to be inconsistent at best.

Keychat allows you to use NIP-55 with Amber to log into ANY web app, because keychat converts it to NIP-07, as though you are signing in using a browser extension. It's much more consistent.

NIP-46 can work, but it is highly dependent on the relay you are using for it, and I think there must be a very short timeout window where, if the client doesn't see the signed event in time on the relay, it just doesn't log you in.

I just eradicated 29 Nostr zombies using #PlebsVsZombies! 🧟‍♂️🧟‍♀️🪓

My Zombie Score was 11%! What's yours?

🟪🟪🟪🟪🟪🟪🟪🟪🟪🟪🟪🟪🟩🟩

Follow nostr:npub1pvz2c9z4pau26xdwfya24d0qhn6ne8zp9vwjuyxw629wkj9vh5lsrrsd4h and join the hunt at: 🏹

https://plebsvszombies.cc

I do. Have for years now. I never seemed to have the trouble others have with force-closed channels etc, but I am also only running my node for my own use, and so I have only a handful of channels, mostly with channel partners I know.

I can also see how running a lightning node isn't for everyone. It takes a lot of understanding of how lightning works, a lot of initial setup, and a fair amount of ongoing monitoring. Most people just want to send and receive sats without all that hassle.

Interesting chart.

I probably would make a different case than they did on a few of those.

Durability: USD in paper cash form is not terribly durable, and can easily burn. Funds in bank accounts have custodial risk and can be confiscated or frozen, which would be another way that it isn't durable. It's inability to maintain purchasing power is less a reflection on lack of durability as lack of scarcity.

Fungibility: The argument that fiat isn't fungible because USD isn't fungible with CAD or other fiat currencies is weak. The same could be said about Bitcoin not being fungible with other cryptocurrencies, or gold not being fungible with other monetary metals. And the spam attack on Bitcoin is very much an attack on its fungibility, by making some sats supposedly more valuable than others, since they have ownership of NFTs attached to them. Fungibility is also closely related to privacy, and I would argue is one of Bitcoin's only weak points. For money to truly be fungible, you have to be unable to trace its history of ownership.

On all the other points I think that Fidelity did a decent job, but I also wish they had more than just the green and orange indicators of which do well and which do poorly. It should have been green, yellow, and red, showing which is the best of the three, which is the worst, and which is somewhere in the middle.

If they had done so, it might have looked more like this:

Otherwise, it implies that Bitcoin is equal to gold on those categories where both have green indicators, but that's not really accurate. In most cases, Bitcoin is actually superior to gold. Likewise, in the areas where Bitcoin shares an orange, negative indicator with fiat on Fidelity's chart, fiat is still worse than Bitcoin, but both of them sharing the same indicator would imply that they are equally bad in that category.

Yep. If Square's option requires manual activation from the merchant, then Zeus is definitely the better way to go. I don't see most average business owners turning Square's Bitcoin option on unless they're already Bitcoiners.

Interesting, that is not how it was being promoted earlier this year.

I think the exciting aspect of Square terminals accepting Bitcoin via Lightning natively is that it will be on by default, so that you can go to a merchant that doesn't know a thing about Bitcoin, pay them with Bitcoin, and they receive dollars.

Those who want to receive Bitcoin can change their settings so they receive Bitcoin instead.

Going the Zeus route is better for merchants who want to be paid in Bitcoin, though, in my opinion.

That's not how number 2 would go.

Number 2 is what governments SHOULD do, but it's also the fastest way to have the bulk of citizens actually riot against them, because so many people rely on government subsidy to get by, which in turn needs money printer to go brrrrrr.

There would be absolute chaos and destruction before austerity ever resulted in healing, and that's only if they managed to hold the line through the ordeal.

GM, brother!

Love the fire, though.

Yeah, but tell me you don't understand Nostr without telling me you don't understand Nostr by calling it a "blockchain DAPP." If there is one thing Nostr very intentionally is NOT, it's a blockchain DAPP.

I thought Primal added Amber login a while back. I believe I updated my review and everything, because it was one of my biggest gripes.

I still have other gripes, but that was one of my biggest.

Mining template decentralization?

I think you are right about consensus ship having sailed, but when it comes to mempool filters, that's not consensus breaking and I don't think anyone is suggesting anything that would be. If they are, I wouldn't support that.

If I understand correctly, the current debate isn't about inscriptions, which primarily use the witness data section of the transaction, making them difficult to differentiate from standard transactions. That is what Taproot enabled and it's debatable what can be done about it now.

As an aside, though, I don't think it is valid to say "Well the consensus was that we wanted Taproot, and the time to stop it was before activation." For consensus to be a valid argument for not doing anything at this point requires that those who supported Taproot activation all were aware that it would enable inscriptions. Otherwise, there definitely was consensus about enabling Taproot, as far as people understood what it would give them, but there definitely was NOT consensus about enabling inscriptions. That can accurately be classified as an unintended use-case of Taproot's features by using an exploit to disguise arbitrary data as part of the transaction's witness section, which no one realized would be the case at the time of activation. That would make it a valid endeavor to patch, if consensus supports activating a proposed patch, in my opinion.

Regarding the datacarrier limit for OP_RETURN, though, that has nothing to do with Taproot. That limit has been in place for years and years. Knots is not the implementation making "a retroactive restriction" on that particular front. Rather, it is Core that is now REMOVING the long-standing datacarrier limit, which was also previously configurable by node runners, but they are removing the option for node runners to set it according to their preferences. That makes the OP_RETURN limit much more akin to the block-size limit, though the change isn't consensus breaking.

100% this is fun!

I would argue that a large part of the definition of what Bitcoin IS directly flows from what it allows and what it rejects regarding transaction construction. Transactions must be denominated in Bitcoin's base monetary units, not in USD, or ETH, or anything else. Yes, that is definitional of what Bitcoin is and is not, but it is also regulatory of what Bitcoin allows to be stored in a block. Likewise, the block-size limit is a regulation on what Bitcoin allows, but one that serves to protect what Bitcoin is: a decentralized, sound, digital money.

Even the early datacarrier limits that have been adjusted over time were regulatory in order to preserve Bitcoin's purpose of being money, rather than a decentralized file-storage database.

And to be clear, we are not talking about filtering transactions by what sorts of things you are spending your money on. A payment to a hooker and a payment to a church are indistinguishable, so it isn't possible to filter one or the other out on the basis of moral qualms about prostitution or supporting a particular church. Nor should it be, since money should be fungible in order to function properly as money. But I think we should be able to acknowledge there is a massive difference between using Bitcoin for its intended purpose as money to BUY an NFT, even if you or I think NFTs are stupid, vs using Bitcoin for an unintended purpose to STORE an NFT.

It's very true that Bitcoin has a very different sphere of authority than the civil magistrate. Yet there is still a very real sense in which Bitcoin is not just a signature validation machine, but an enforcer of a moral standard, just as surely as the civil magistrate ought to be. A peaceful enforcer, to be sure, but an enforcer nonetheless.

Take Bitcoin's supply cap. That is the instantiation of a moral principle into Bitcoin's code; namely that your money shouldn't steal from you, but should be a lasting abstraction of your productive time and energy that should grow in value over time, rather than shrink. Not everyone agrees with that statement, either. Plenty of folks out there think a monetary system that doesn't steal value from its holders is unworkable.

Even the purpose of signature verification you mentioned is based on a moral principle that no one should be able to take the value someone else has earned. Rather, each person should be able to dispose of his property voluntarily as he sees fit. Cryptographic signatures just ensure that moral principle is protected by inviolable code.

We could move on to mining and the difficulty adjustment. Both of these core aspects of Bitcoin exist to enshrine the moral principles that 1.) no one should be able to arbitrarily create value for themselves without work, and 2.) that no one should be able to reverse a transaction without the consent of all the parties of that transaction.

Most of these are just different outworkings of the basic principle "thou shalt not steal," of course, and applied to how a money ought to be designed to make various forms of theft difficult, if not impossible. Moreover, they are imposed unilaterally, in spite of the fact that there are plenty of people out there who disagree with many of the details of exactly how that basic principle ought to be reflected in our money.

I am torn on that. I think there is a place for civil law to be a reflection of moral law.

Indeed, I think each an every law that is on the books is an expression of SOMEONE'S morality. The question of how just a law is comes down to how well it reflects the only true morality, which is God's law, and therefore how well the civil magistrate fulfills his God-ordained duty to be a terror to the evil-doer and rewarder of the good.

I am not terribly moved by the legal liability argument. I will gladly endure the persecution of a hostile state for standing up for what I believe is right.

I am, however, moved by the moral argument.

I look at it similar to the porn issue on Nostr. I run my own relay, and I am under no illusions that filtering porn from my relay is going to make much impact on Nostr as a whole at all. However, I can have a clear conscience knowing that I am not contributing to it with my relay.

Same with filters on my node. It's not going to have a lot of impact on keeping non-monetary transactions, especially those containing data I find to be immoral, out of the blockchain, but I will know that my node is not contributing to the problem, and since I am creating block templates with my node's mempool, I know that if I ever found a block, it would not be contributing to the issue.

So I see a lot of reason to have the option to filter your mempool if you want to do so as a node runner, and that taking that option away is not the route we should be going. Not so node runners can bend to the will of any state, but so they can be faithful to what they believe is right. Particularly since doing so in this context in no way imposes their view of what is right on anyone else. They are deciding it only for their own individual node.

I came from western Washington, so when we decided to move to Idaho to seek out a bit more freedom, I knew we needed to go somewhere that still has a lot of trees. Grateful we landed here in North Idaho.

Hope to catch you up here next year.

Wish I had known! I had a busy summer, but definitely would have tried to get together for a beer while you were here!

There's definitely a good contingent of Bitcoiners in the OPC, and even here on Nostr.

Streaming worked well multicasting to several places, including Nostr, so we're going to keep it up.

In fact, this weekend I'll be the one filling the pulpit while our pastor is on a short vacation.

In this you rejoice, though now for a little while, if necessary, you have been grieved by various trials, so that the tested genuineness of your faith—more precious than gold that perishes though it is tested by fire—may be found to result in praise and glory and honor at the revelation of Jesus Christ. — 1 Peter 1:6-7 ESV

nostr:naddr1qpqrjdfsx5ckzcnpxsekgcekv93nvvejxgmr2vehv5exyv3evy6x2vmzv33kywty8qckgefjvcmkyetrvvunqc348ycrzer9xq6nsvrpxuq3kamnwvaz7tmjv4kxz7fwvfexjemgw33x7mr59ehx2ap0qgstwf6d9r37nqalwgxmfd9p9gclt3l0yc3jp5zuyhkfqjy6extz3jcrqsqqqakz5fx05j

Able to create invoices fine from my Alby Hub using Alby extension or Alby Go.

For sure! I appreciate the feedback!