hoppe2

It reminds me of how hardcore Bitcoiners used to trash gold over storage costs whenever they argued with gold bugs. From my position of holding both, I thought 'that's really not true at all,' but I didn't bother jumping in.

2026-08-04 17:49:42 CEST

- reply

I heard the other day that when putting funds into a Nostr app — specifically into a Taproot address directly tied to a pubkey (as implemented in Amethyst or Ditto) — it's a good idea to only put in an amount suitable for use as a canary to detect whether the nsec has leaked, and that made sense to me.

2026-08-04 02:18:28 CEST

- reply

2026-08-03 09:56:21 CEST

- reply

2026-08-02 16:39:28 CEST

- reply

Actually, things like 'no-log' policies or 'we delete customer data' claims can't really be verified, so it was probably inappropriate for them to market that as a competitive advantage in the first place. And honestly, people shouldn't have believed it even if they claimed it. I never believed this kind of 'no-log' stuff anyway — I always figured deleting data is extra work, so they're probably just not deleting it.

2026-08-01 15:01:40 CEST

- reply

Good morning. I recommended gathering Bitcoin to everyone I know, but no one listened to me except my parents, and even my parents didn’t transfer it from exchange. It was a bit frustrating, but this time it seemed like my parents were right. Even if it just means paying a bit more in taxes, I think it’d be better for my parents’ Bitcoin to stay there.

2026-08-01 14:58:23 CEST

- reply

GM Derek

2026-07-31 15:53:57 CEST

What’s the best way to connect to Chinese open-source models like GLM 5.2, DeepSeek, or Kimi? Would something like OpenCode be good? I’ve only used Claude Code with Opus, so I’m not really sure. I’m a bit tight on money lately, so I probably need to look for something cheaper.

2026-07-29 02:08:21 CEST

gm. I miscalculated the date and realized that something I thought could be reset today actually turns out to need waiting 10 more days.

2026-07-27 06:40:05 CEST

I’ve decided I can confidently recommend Nostr to people around me once DMs are reliably delivered in about the top 5 apps by usage.

2026-07-27 02:12:31 CEST

- reply

That’s exactly why all those things—RWA, STO, and the like—are basically scams.

2026-07-22 17:56:51 CEST

- reply

Even doing it that way, the eggs still seem to stick a little.

2026-07-22 17:47:41 CEST

- reply

Although I'm not Japanese myself, as someone from the neighboring country, I can't help but chime in — I don't know about vegan pizza, but vegan sushi is honestly a ridiculous concept. It's an insult to sushi.

2026-07-22 02:42:39 CEST

The most frustrating thing about Lightning is that, no matter how well I set things up, a payment fails if the counterparty’s side is misconfigured. The second annoyance is that when a payment fails, it’s hard to tell right away whether the problem is on my side or the other party’s. A better solution is needed.

2026-07-21 17:28:43 CEST

- reply

how can i access fips?

2026-07-20 12:56:39 CEST

In the past, while building a Nostr-related app, I realized that Nostr's pub-sub model lets you act as a server without needing a domain or a fixed IP — and I thought that was incredibly useful.
Around the same time, looking at Lightning Address, I thought it was kind of lackluster, but figured it was unavoidable if you wanted a fixed receiving handle.
Then not long ago I finally saw CLINK. Why didn't I think of that?!

2026-07-17 14:18:21 CEST

- reply

I'm looking for ways to earn money with Bitcoin from the start, so I can get out of this terrible fiat-mining job. I need to get it done as quickly as possible.

2026-07-16 03:37:12 CEST

I think I’ll get fired at work this year. Being a developer doesn’t seem to suit me, so I’m considering doing manual labor.

2026-07-15 05:48:38 CEST

- reply

Is OpenCode better than Claude Code? Or do you use OpenCode because it's more suitable when switching models?

2026-07-15 02:43:16 CEST

I’m wondering whether there is a “pay‑to‑read” service on Nostr. On many platforms, if I click a link to read an article, I’m immediately prompted to log in, so I just close the page. A micro‑payment system could be a better solution for that.
Legacy social networks don’t have built‑in payment features, so it seems impossible there, but with Zap and Lightning becoming common on Nostr, it should be feasible, right?
Would it be difficult to implement the part that receives the payment and distributes it? I haven’t thought about it deeply yet. In my usage pattern, when I click a link to a long‑form article that interests me on Nostr, I’d probably be fine with a small payment request. Nostr makes it possible with a single click.

2026-07-14 02:33:24 CEST

- reply

It happened to me too, haha.

2026-07-09 05:49:18 CEST

- reply

Laws and order should not be constraints governing us, but services we voluntarily choose.
In other words, all matters must be based on mutual agreements.
For example, private insurance companies could provide judgment services.
Someone might argue, "Without a single unified legal system, disputes will never end."
However, the response would be: Even now, disputes with foreigners aren't governed by a single law, yet they generally function effectively.

2026-07-08 19:08:03 CEST

- reply

Ark has the same "back up your proof every vtxo" requirement. And the same limitation: the moment you receive offchain vtxo(and proof), you can unilaterally exit, but it isn't exclusive either — a colluding previous owner + ASP could still double-spend your prior state.
What's better about Ark is the periodic batch round (an onchain tx). When you participate, your old VTXO gets forfeited, which kills the stale state a prior owner could've exited with — so exclusivity is restored and only you, the latest owner, hold full ownership.
And the batch settlement is O(1) onchain regardless of participant count — thousands of participants still settle into a single shared Taproot output that just looks like a normal address. (You only unroll the tree if you unilaterally exit.) That amortizes the fee across everyone, so at scale the per-user burden becomes almost negligible.

2026-07-08 18:52:57 CEST

- reply

The DA dependency isn't really the issue imo — if a holder backs up their proof each tx, a withheld proof just means it's treated as unreceived. Worst case a UX problem, handled in the background.
Spark's real problem, as I understand it, isn't that — it's that even with every proof in hand, you don't quite get true self-custody. Not because UE is impossible, but because it may not be exclusive: as I understand it the federation can equivocate, so a colluding prior owner could double-spend. And if exit exclusivity rests on federation honesty, that's not self-enforcing — or am I missing something?

2026-07-07 10:18:35 CEST

- reply

korea 😂

2026-07-07 02:17:13 CEST

- reply

I want to try it, but there’s nowhere to get it here.

2026-07-03 02:16:05 CEST

https://npub1pt4qwkcpp76et45pfatrxqywsuxh0gky84xa592yapesuqye29zql4eera.blossom.band/4c6c4ad6860824e6e8d7b3070127bb6a5775e5dca1e99aedc9bb28db7ed41cab.jpg
3 hop 0 fee
first time seeing something like this

2026-07-01 17:51:01 CEST

- reply

wallpaper

2026-07-01 13:36:09 CEST

- reply

When the spec actually said it uses the same cryptographic scheme as Bitcoin to create identities, I did think, "Ah, so it derives the same key into a Bitcoin address and uses it to send and receive money." Because I heared it's a Bitcoin native protocol...

2026-07-01 13:28:02 CEST

- reply

Yeah. Before even getting to the argument that " delegating simple tasks to AI frees up time to focus more on design" — in my case, I probably wouldn't have even thought about building anything in the first place if AI hadn't existed.
Recently I had to deal with handling a zero-confirm tx (obviously not talking about on-chain stuff, haha), and going through the process — proposing an approach, getting rebutted by AI, then re-rebutting AI's suggestion, and finally reaching a conclusion — I learned a lot along the way.

2026-07-01 11:48:34 CEST

I've noticed a lot of controversy in Western societies about introducing ID numbers. Since I live in a country that adopted this system decades ago, let me give you a heads up on a few things:
Every single time you sign up for something, you'll experience hell.
Site operators will also experience hell trying to manage all that personal data.
You'll see news about personal data breaches pouring in almost every day.
Using issue #3 as an excuse, they'll demand even more personal information under the pretext of better distinguishing identity theft from legitimate use.
Idiots won't realize this whole mess stems from government policies that force companies to collect personal data in the first place—instead, they'll blame companies for "failing to manage it properly," causing social division.
Enormous amounts of time and manpower will be wasted handling personal data that never would have been leaked if it hadn't been collected in the first place.
Under the pretext of protecting personal information, government intervention in corporate operations will expand dramatically

2026-07-01 03:14:43 CEST

- reply

Batch openings don't seem to provide much scalability benefit, but sharing outputs could be significantly helpful — arc is considered to be implemented for this purpose. While it may not offer the immediate finality comparable to Lightning, it pertains to an area where economies of scale apply. In the future, large-scale ASPs will be able to conduct batch settlement transactions in every block, and when that happens, Arc enables:
1. Cheap utilization of vtxos with unilateral exit rights reset every block.
2. Much more reliable operation for zero-conf payments (here, meaning participation in a batch round rather than onchain confirmation) due to the incentive model — since it’s not anonymous customer but ASPs maintaining an ongoing business that must cooperate.

2026-06-30 09:09:13 CEST

- reply

What percentage of messages are spam for an account as popular as yours? Is the spam filter active, making it impossible to check?

2026-06-29 03:52:34 CEST

- reply

There's a similar warning about not using hotel shower heads—advising either not to use them or to bring your own personal shower head to replace it. The reason is rather hard to talk about frankly.

2026-06-24 13:16:41 CEST

I just eliminated 23 Nostr zombies using #PlebsVsZombies! 🔪🧟‍♂️🧟‍♂️
My Zombie Score™ was 10%! What's yours?
🟪🟪🟪🟪🟪🟪🟪🟪🟪🟪🟪🟪🟩🟩
Follow @npub1pvz…sd4h and join the hunt at: 🏹
https://plebsvszombies.cc

2026-06-13 08:58:11 CEST

- reply

If we're talking about things we can do at an individual level:
1. There are many things that are illegal but don't actually violate anyone's private property—if you've been in the habit of reporting such things, stop doing that immediately.
2. Encourage tax evasion.
3. Persuade others to join in on points 1 and 2 as well.
4. Advocate for, use, and spread the freedom-enabling technologies that make it easier for others to do these things.
5. Above all, stop voting.
6. Exclude, as much as possible, the voluntary Gestapo who can't be persuaded.
In fact, there's one path that's the easiest way to put all of this into practice—one that requires no special effort and is even beneficial to do: save in Bitcoin and pay in Bitcoin.

2026-06-11 15:29:27 CEST

- reply

I used to have this goal of building a sleek Nostr client like yours, so I'd pore over the NIPs. After reading through them multiple times, I came to the conclusion that I should find something else I'm actually good at haha

2026-06-11 13:33:32 CEST

- reply

And this goes without saying, but... it's not just about tagging — the client also needs to look up the inbox relays of every tagged person and publish to those relays as well.

2026-06-11 13:29:09 CEST

- reply

The reason the notification isn't going through is that the problematic note isn't tagging your pubkey. Also, per the Nostr standard spec(NIP), in order to send notifications properly, client is supposed to tag everyone involved — meaning all participants from the root note all the way down to that comment — but it looks like Wisp only tags the pubkey of the immediate parent note.

2026-06-03 05:49:48 CEST

- reply

Most of my NIP-46 issues come from the OS killing my processes. It's never been an issue on Linux, but mobile has been a constant struggle

2026-05-31 08:37:33 CEST

- reply

Just to clarify — this is a general statement; I don't know what this app does.

2026-05-31 08:36:29 CEST

- reply

Right — logging in or signing up is really annoying. For most use cases, an automatically generated private key stored in the browser is enough, provided there's some protection against spam attacks (or the app doesn't need spam protection).

2026-05-21 02:47:41 CEST

- reply

Basically, all financial products, including insurance, are just a gamble. But to be more precise, that 'gamble' is just an excuse to take people's money. They collect cash from users under that pretext and use it to buy assets. In the end, they’re just shorting the dollar using our own money, and we’re paying them a fee to do it for us. We could literally just do it ourselves for free.

2026-05-20 02:26:14 CEST

- reply

I've actually built a fully non-KYC service before, and the thing is, it becomes extremely vulnerable to spam attacks. Then you end up piling on all this complexity just to mitigate it, and from the user's perspective the UX becomes genuinely awful. Anyone on Nostr probably feels this to some degree... and then what happens is maintenance becomes a nightmare, users go "wtf is this, it sucks, I'm out." That's just how it goes.
The other classic solution is using reputation to filter spam — but then we basically just killed the whole point of anonymity

2026-05-18 15:37:27 CEST

People say on-chain zaps are dangerous because they make you a target. But here's the thing: if that's actually true, then promoting "accumulate Bitcoin as money" is way more dangerous. A couple months of salary gets you way more Bitcoin than someone could ever get from zaps in a lifetime.
So either the security risk is real—in which case these people shouldn't be publicly known Bitcoin advocates in the first place—or it's not that serious. You can't have it both ways: tell people to accumulate Bitcoin while also warning them not to be seen with Bitcoin.
Ironically, Krugman or Schiff staying quiet might actually be the most consistent move here. If holding Bitcoin visibly is dangerous, then not broadcasting it is the smarter play. These vocal Bitcoin advocates are basically contradicting their own security argument.

2026-05-18 11:13:49 CEST

- reply

When I first heard about Nostr—introduced as an SNS protocol built by Bitcoiners—I read a document explaining that it solves the identity verification problem the exact same way Bitcoin does.
So I thought, 'Ah, if it uses public-key cryptography for identity and shares the same elliptic curve as Bitcoin, then a Nostr account itself could basically function as a Bitcoin address. That’s what they mean by Bitcoin-native.'
As it turned out, that wasn't the case at all back then. But what I envisioned back then is finally being implemented now.

2026-05-14 15:06:00 CEST

- reply

what client have this option?

2026-05-13 02:29:19 CEST

I've been thinking about inheritance, and I discovered something called the Liana wallet. It seems almost like a perfect solution.
I created a script address that allows me to spend without any restrictions, while adding a time-lock condition for heirs—giving them the ability to spend after a relative time-lock of one year. No third parties or additional requirements needed.
As long as I don't die suddenly and my heir doesn't simultaneously lose access to their device, it's quite secure. And since the script allows great flexibility, I can enhance safety further by using multiple keys in a multisig setup, while maintaining the same overall structure.
As long as I remember to make one on-chain transaction every year, it should be nearly perfect.

2026-05-12 02:33:39 CEST

- reply

and do not enable auto-update

2026-05-10 07:33:58 CEST

There used to be a few things about real estate that I just couldn't wrap my
head around.
Take the 'squatting' controversy in the West, for example. The idea that someone
could illegally occupy a vacant house, stay there long enough, and suddenly gain
rights that make it impossible for the owner to evict them seemed absurd. I
honestly thought America was turning into a socialist country when I first heard
about it.
Then there’s the fact that anyone can legally snoop on a property's registry
just by knowing the address. I couldn't understand why complete strangers were
allowed to check if a house was rented, owned, or heavily mortgaged just to
guess someone's net worth.
Or the lack of absolute 'legal conclusiveness' in the real estate registry. You
hear these incredibly unfair stories of people buying a house trusting the
official state ledger, only to lose their home later because the ledger had been
forged sometime in the past.
And finally, the concept of a tenant's 'opposing power'—the rule that a tenant
must officially register their move-in to protect their deposit. I always
thought, "If I signed a lease and handed over my money, shouldn't my deposit
just be naturally guaranteed?"
Life is full of laws that don't seem to make sense, so I mostly just brushed
them off at the time. But as I dove into Bitcoin and started questioning what it
truly means to 'own' something, all these disjointed mysteries suddenly clicked
into place.
The complex rules around a tenant's rights exist for a very specific reason. A
lease is basically a private contract (a claim) between the tenant and the
'previous owner.' When the house is sold, from the perspective of the new owner
who legitimately paid for the property rights, it is logically correct to argue,
"Your deal was with the last guy, not me. Get out of my house."
But what happens if the law just unconditionally protects the seemingly
vulnerable tenant? A scammer could take out a massive mortgage, default on it,
and then pull out a fake, backdated lease agreement made with a relative to
screw over the bank when they come to seize the asset.
That is why 'public disclosure' is required. By making the existence of a
legitimate contract public at a specific time (like registering a move-in date),
the government promises to review and recognize that right later. It’s a
compromise. And the reason anyone is allowed to look up another person's
property registry is precisely to maintain this public disclosure system.
But herein lies the critical dilemma: the ledger managed by the government—which
effectively acts as a 'monopolistic sequencer'—doesn't perfectly guarantee the
truth.
This is exactly why courts don't grant absolute legal conclusiveness to the real
estate registry. Historically, there have been too many cases where the name
written on the state ledger didn't match the true owner of the land. Fraudsters
have long exploited wars or administrative chaos to manipulate the ledger and
hijack property rights while the true owner was unaware.
So, to make up for this flawed ledger, what happens if the law starts
prioritizing 'actual physical possession' over paper documents? You end up with
the exact squatting crisis we see in the West today.
Whichever path is chosen, scams exploiting the legal loopholes will inevitably
follow. The fundamental reason real estate is so legally tangled and fraught
with endless lawsuits is that, technically speaking, perfectly proving ownership
of a physical asset is impossible. It can only ever be 'presumed.'
High-level verification requires massive costs. People wanted to protect their
assets but didn't want to bear those verification costs, so they handed this
complex arbitration over to a central authority: the government. This has become
the root of many modern social problems. When the government unfairly takes a
side, or when it becomes a player itself and intervenes in the market, we are
left completely defenseless.
This is the core reason why I don't see real estate as the ultimate store of
wealth. I look beyond simple inflation hedging to the true essence of an asset:
"Can I truly own it? Can I prove my ownership without needing anyone's
permission?"
For me, the only assets that pass that test are physical precious metals and
Bitcoin.

2026-05-09 13:18:17 CEST

I’ve previously mentioned that I wasn't entirely convinced about the future of Bitcoin. To put it briefly, my argument was that even with the Lightning Network, there are inherent limitations to Bitcoin evolving into a global-scale payment solution. I was curious to see how Bitcoiners would respond to this, but at the time, I received no answers, which led me to believe it might be an unsolvable problem.
However, I recently started looking into Layer 2 solutions other than Lightning, and I found one that seems quite promising: the Ark protocol. While it’s impossible to explain exactly how it functions in a single post, the conclusion is that it appears to effectively address the limitations of Lightning.
Based on my understanding of their documentation, here is how the UX of Ark works:
Off-chain payments do not provide the same level of finality as Lightning immediately. To achieve Lightning-level finality—meaning no one can touch my funds, and I am cryptographically guaranteed a unilateral exit to Layer 1 without relying on anyone else—I must participate in what is called a 'batch settlement transaction.' This is an on-chain transaction that anchors to Layer 1 to achieve finality.
One might ask, 'If it requires an on-chain transaction, how is this a scaling solution?' The key is that this batch settlement transaction involves multiple people simultaneously, allowing the fees to be shared among them. Furthermore, the size of this batch transaction does not scale proportionally with the number of participants; it remains a fixed size.
In other words, it is an on-chain transaction that enables true 1/n cost efficiency. With Lightning, the decisive obstacle to global scale is that when you open a channel, you have to pay for that on-chain transaction yourself. Ark solves this by allowing for massive, shared efficiency. If this becomes fully realized, it is theoretically possible to achieve self-custody without ever needing to make an on-chain transaction in your lifetime.
This is made possible through Taproot and other technical mechanisms, and based on my current knowledge, it seems theoretically sound. While it still requires code-level verification, this discovery has resolved my only lingering doubt about Bitcoin. I now have genuine hope that it can function as a global-scale payment solution.

2026-05-05 05:51:39 CEST

- reply

https://ark-protocol.org/
you means this? I’m also looking at this lately, and it seems promising. My only worry about Bitcoin is that—even if every micro‑payment were made exclusively through Lightning channels—true self‑custody would require every person to have at least one channel. With the current architecture, just creating a single channel per person would take decades, and the problem only gets worse as the population grows. According to Ark’s documentation, in the ideal case a unilateral escape can be cryptographically guaranteed without a single on‑chain payment, although each batch settlement still needs an on‑chain transaction—but the fee could be $1/n$. That suggests a massive scale‑up possible in a way that differs from Lightning. I’m reviewing the theory and the code to see if it’s real, and I’d like to hear other well‑known developers mention it as well.

2026-05-01 04:47:55 CEST

I'm trying to switch the wallet setup in my phone's Nostr client to use a local relay (specifically @nprofile…utvn) and @zeus for fast responsiveness, but it doesn't work properly in almost all clients.
I suspect it's because they automatically block WS connections instead of WSS. Only amethyst allows zaps, but even there, balance and history checks don't work.
Blocking WS is fine, but localhost should be whitelisted as an exception.

2026-04-29 02:11:03 CEST

- reply

Doubt everything the government tells you. Above all, if they say something is for your own good or offer it for free, treat it as a falsehood until proven true through mathematical certainty.

2026-04-28 02:44:48 CEST

- reply

So BitVM has that issue? If I'm understanding correctly, Bitcoin L1 can't verify ZK proofs at consensus level, so anchoring relies on operator good faith?
If that's right, then maybe the more natural approach for Bitcoin L2s is to compose only from primitives that L1 can directly verify. Ark protocol seems to fit that mold - periodic batch settlements using only what L1 natively understands, with each settlement providing on-chain finality at fees split across all participants.
Curious whether you've looked at how Ark handles this differently, or if you see issues with that approach too?

2026-04-26 17:11:25 CEST

- reply

I’ve always thought it was strange that Nostr clients implemented showing an npub as a QR code but didn’t implement scanning QR codes. Of course, I’ve never actually had a situation where I needed to scan someone’s npub when meeting them offline, so it’s never really caused any trouble lol.

2026-04-23 12:46:09 CEST

@npub1xnf…lpr5 Apps connected via NWC are extending beyond a single page, but scrolling isn't working, so the initially registered ones are not visible.

2026-04-23 02:25:36 CEST

@nprofile…4u96 How do I get rid of the red inquiry button floating on the screen? It's really annoying.
https://npub1pt4qwkcpp76et45pfatrxqywsuxh0gky84xa592yapesuqye29zql4eera.blossom.band/a23f2798e74cd99c864028bd1c03cf395586346987b6a5aafd238f88e3449230.jpg

2026-04-20 14:53:48 CEST

- reply

especially in the case of Nostr, it's even more so.

2026-04-20 09:11:11 CEST

- reply

Someone's treating a nostr relay like a free backend. The data probably only matters within their own app. But if they had any sense, they wouldn't be using kind 1—what an asshole.

2026-04-19 11:57:32 CEST

Am I the only one who thinks it's weird that the playback bar, play/pause button, or settings button cover the video when watching? Isn't this way too annoying?

2026-04-19 06:32:27 CEST

- reply

test

2026-04-19 03:07:25 CEST

https://zapstore.dev/apps/com.hoppe.cliprelay
I had Claude build me a clipboard sync tool using Nostr. I've always found it extremely cumbersome to copy something on one device and paste it on another by having to open a messenger app, find the chat-with-self room, paste it there, then on the other device open the same messenger, go to that chat room, tap on the message, and copy it again.
Sure, similar tools probably exist out there, but these days with Claude around, it's so quick to just ask an AI to build it—so I went ahead and made one.
Here are the app's key features:
- Supports only NIP-46 login (direct use of private keys is not supported. Aside from security concerns, the problem remains of how to transfer that private key to another device. Isn't it ridiculous if you still have to use a messenger just that one initial time to send it over?).
- Tracks in real-time the relays and Blossom server specified by the user, and transmits data through those servers.
- Text is encrypted using NIP-44 self-encryption; images are encrypted with an AES-GCM one-time key, then the encrypted binary is uploaded to Blossom, while the SHA-256 hash and decryption key are sent via NIP-44 encryption. General file types (beyond images) are not currently supported.
- Supported on Windows, Linux, Mac, and Android; iPhone is not supported.
- Usage: On desktops, after installation and login, there’s nothing else to do—copy on one device, and it automatically appears on the other's clipboard. On mobile, there is a persistent notification—after copying, tap the persistent notification to send it to the other device. When receiving, a separate incoming notification appears (distinct from the persistent one), and tapping it copies the content to the clipboard.
- Currently free. I'm considering a payment system for the future—specifically when large file support is added, I'm thinking of passing charges directly through the Blossom server (not that I intend to collect payment directly). Enabling economic incentives for Blossom server operators was actually one of my motivations for building this app. I plan to support it once a smoother payment standard emerges.
- On mobile, the app attempts to stay running continuously unless explicitly closed by the user (though this cannot be guaranteed).
- Care has been taken to ensure plaintext is never stored outside the app’s own storage (e.g., in notification systems), though this cannot be fully guaranteed.
- Clipboard history is stored plaintext on the device itself.
- Logging out deletes authentication data along with the history.
- The NIP-46 communication private key is stored in the OS-specific secure key storage.
I’ve put effort into encryption, but given my own technical limitations, I can't be certain there are no data leaks somewhere. I do not recommend using this app for highly sensitive or critical information. It’s intended only for everyday, routine use—something that replaces the kind of casual content you’d previously share over messenger apps.

2026-04-14 03:07:20 CEST

- reply

Right — and that's precisely why Milton Friedman created the withholding tax system. Isn't the fact that this kind of communism is labeled as libertarian proof of how pervasive state control is?

2026-04-14 02:46:26 CEST

- reply

It's been shown that's not the reason, lol.

2026-04-13 15:19:50 CEST

- reply

Maybe their profile metadata isn't on their write relays, or they haven't specified any write relays at all. Some clients might just be 'smarter' and fetch profile info from major relays automatically, which is why it shows up there

2026-04-04 19:22:04 CEST

CTO wants to have a 1-on-1 meeting on Monday. It seems like the time has finally come. If I get laid off, I should take a good two-month break to rest.

2026-04-01 17:04:52 CEST

- reply

I've been on a low-carb, high-fat diet for several months, and yesterday I had my first health checkup since starting it. The doctor saw the results and said I should come in immediately for a consultation haha.

2026-03-20 01:10:42 CET

Nostr client developers really need to make it easier to add friends via QR codes — especially when meeting users in person, not just following them online.
Many clients are quite inconvenient in this aspect, and some don't even have this feature at all. It's unreasonable to expect users to manually type long public keys, and given that Nostr is decentralized, search functions are already limited. It’s frustrating that even when you meet someone in real life, adding them as a contact can be such a hassle.

2026-03-19 13:50:37 CET

- reply

make sense

2026-03-19 01:43:00 CET

- reply

Great!!

2026-03-19 00:15:38 CET

- reply

I clicked to check the details, and it said the connection wasn't secure. But when I clicked again, it suddenly said there was no problem with the certificate. I'm not sure what's going on. I tried to capture a screenshot of the English message, so I switched the settings to English, and then it suddenly showed everything as normal with no issues. Then, I switched back to the local language, and now the warning has disappeared. It seems like there might have been some issue with the local language version. Not sure what caused it, though.

2026-03-18 16:17:44 CET

- reply

I already starred it before, so I tried leaving a zap, but it didn't work. It says it's not connected to the NWC relay. Could this be related? Maybe the domain certificate has expired or something...
https://npub1pt4qwkcpp76et45pfatrxqywsuxh0gky84xa592yapesuqye29zql4eera.blossom.band/0572e7207f419c1955bed9e4ca7c83f691fe61610e0959cc79da110f614407d2.jpg

2026-03-18 15:02:24 CET

- reply

Yeah, it's really frustrating. When I first encountered Nostr and heard it was trying to solve the problem that other social networks don't show notes from people i follow in chronological order, I didn't really understand it—especially as someone who doesn't really use social media. But lately, I've come to understand it perfectly.

2026-03-18 01:54:14 CET

- reply

It's hard to reverse a negative first impression, so I believe it's better to ensure at least minimal usability and comfort before promoting a service. Besides, it's difficult to recommend a social platform (whether a microblogging app, messenger, or anything similar) if users aren't confident that their direct messages will actually be delivered.

2026-03-18 01:25:24 CET

I was using Zeus Wallet and thought I wouldn't need Alby anymore since it supports NWC, so I uninstalled Alby. But it turns out Zeus isn't as reliable for payments—while it works fine when using Zeus directly, it often fails when connecting through apps via NWC. Probably because Zeus runs locally on mobile, whereas Alby operates via server. Looks like I'll have to reinstall Alby.

2026-03-18 01:14:17 CET

- reply

permanent storage (best-effort) for paid users, and volatile storage for free users to save space

2026-03-13 01:33:45 CET

- reply

I see that spam filtering is being handled, but simply blocking known spammers every time isn't a real solution. Eventually, is WOT (Web of Trust) the only answer? Or perhaps a PageRank-like scoring system based on extensive collection of kind 3 events?
I'm also curious how your relay operates. I've considered attaching tiny amounts of e-cash as economic incentive for relay operators, which could contribute to a healthier ecosystem. But since events are commonly pooled and broadcast simultaneously to multiple relays (especially since there are usually several tagged recipients in a p-tag, and each user likely has at least two or three inbox relays), I'm not sure users would accept the added complexity. Plus, managing different policies(price) across relays would make implementation quite cumbersome.

2026-03-12 01:49:58 CET

- reply

Oh, I see. thk

2026-03-12 01:34:24 CET

- reply

You mean this is a non custodial wallet? But how is that possible if I'm not running my own Lightning node and opening channels myself? Given how quickly the setup was completed, it doesn't seem like an embedded LN node is being used either.

2026-03-03 09:01:27 CET

- reply

I tried to leave a review, but it asked me to break through the captcha, so I just left a zap instead ✌

2026-02-24 00:49:55 CET

I'm currently using @nprofile…vavr mint through @nprofile…p4uv , and I'm reaching out with a question. I'm personally developing a service that requires payment via hold invoice, and during development, I was testing the expiration/cancellation behavior by paying a hold invoice using the Keychat Cashu wallet. The payment attempt initially seemed to fail—although the payment did reach the recipient side, it remained in a "pending" state since it wasn't settled, which is expected. I didn't mind the unclear UI indication, since most wallets don't clearly display pending states anyway.
However, the next day, after the invoice expired as intended and the payment properly failed, I noticed that the deducted balance in my Keychat wallet wasn't restored. Normally, when a hold invoice is canceled, the mint's Lightning node should recover the funds and reflect that credit back to the user's balance. If this were my own Lightning node, the balance recovery would have happened automatically. But with the Cashu wallet, since I had already paid ecash to the mint to initiate the payment, my balance was deducted up front. From the mint’s perspective, once the ecash was spent, the balance was marked as spent—even though settlement never occurred. And since the control had already been effectively transferred, the mint likely considered the payment as completed on its end. It doesn’t appear to track the subsequent cancellation status.
Moreover, due to the anonymous nature of ecash, the mint likely can't identify who made the payment—even if they wanted to issue a refund, it might not be possible. I can provide proof of the hold invoice and confirmation that it was ultimately canceled (via DM). Surely a refund shouldn’t be impossible? I understand it might not be easy to verify, and while I understand if no refund can be issued (it's only 5,028 sats, not a large amount), this highlights a bigger issue: going forward, such payments need to be properly handled. Otherwise, it effectively means users permanently lose funds to the mint even when payments fail. This isn't just an issue with Minibits, but likely all #cashu mints. A proper mechanism needs to be developed to handle these cases.

2026-02-20 01:43:06 CET

- reply

GM. It's nice to see someone on Nostr who's in the same time zone as I am.

2026-02-08 07:58:53 CET

- reply

I thought the spec said that files with identical content should always produce the same hash, but in practice, that doesn't seem to be the case. It looks like the hash is being generated by including metadata such as upload time as well.

2026-02-03 06:39:06 CET

- reply

Even if it's possible to make the exact amount with the current token combinations, it still ends up using just the tokens I have on hand, which can result in multiple inputs—like sending 256 using two 128s, for example. Swapping to send a single 256 token looks cleaner. But would making that the default behavior be wasteful due to the extra network round trip?

2026-02-03 02:53:40 CET

- reply

It would be great if, when issuing tokens, it could automatically send the exact amount using the minimum number of tokens—like finding the optimal combination. If the available tokens can't form the precise amount, it could fetch suitable denominations from the mint to make up the difference. It would be convenient if this were handled automatically at the library level. Do you know if such a feature already exists?
@nprofile…xnfk @nprofile…vcku

2026-02-03 02:47:24 CET

- reply

Yeah, that's right. I've seen others solve it by creating animated QR codes, but that brings compatibility issues and loses the charm of printing and handing it over, lol. But if we just make it tiny and packed, it probably won't scan well either...
For now, I'm just sticking to issuing tokens in denominations that match Cashu's unit (like 256 or 128), so I don't need to include that many tokens anyway—this works fine for me.

2026-02-01 12:53:09 CET

There's a feature in Keychat wallet where sending "pay ecash" returns an ecash token, but sometimes it comes with a QR code and sometimes it doesn't. What's the difference? I'd like to provide a smooth experience where users can simply pass along a QR code, but when it only returns a token, I have to send it via DM, which is a bit inconvenient.
#asknostr @nprofile…p4uv

2026-01-31 03:45:13 CET

- reply

Also can I convert my current balance into an eCash token form and send it to someone else? I'm trying to transfer the full amount cleanly without leaving change in my yakihonne wallet. @npub1yzv…rf8q

2026-01-31 02:41:46 CET

- reply

Is it not possible to receive a Cashu token in the form of a QR code? I thought the "Redeem" option at the top was meant for that, but it doesn't seem to work.

2026-01-27 01:46:18 CET

Sometimes, while using a VPN, Nostr-related apps occasionally fail to work properly. Since they always start working again as soon as I turn the VPN off, it's nearly certain that the VPN is the apparent cause. I initially thought the VPN might be blocking WebSocket connections to relays, but since the apps often work perfectly fine even when the VPN is on, that doesn't seem to fully explain it. What's more puzzling is that @npub142g…xrj0 always works without any issues, regardless of whether the VPN is active or not. I can't figure out the reason for this inconsistency.

2026-01-16 01:41:12 CET

- reply

Full compatibility? cool. Does it provide migration support for makers? Those with fidelity bonds might find switching difficult, so it would be ideal if simply copying the existing data folder would allow full functionality.

2026-01-16 01:31:01 CET

- reply

jumble is my favorite client in terms of UI, but it definitely has a bit of a loading lag—especially during initial startup. I've always thought that Nostr clients would benefit greatly from an architecture where a separate background process handles subscription to relays and manages writing events into a local database. Would the development complexity increase drastically with this approach? Perhaps, but I believe the advantages gained from such a design would be substantial. While completely rebuilding existing clients might not be practical, I hope developers creating new clients will seriously consider this kind of architecture.

2026-01-14 11:42:20 CET

- reply

I'm currently using the Qwen3 235B A22B 2507 model. Are there any newly released models that offer better performance and better cost-effectiveness? For example, models with nearly similar performance but significantly cheaper, or slightly more expensive models that deliver much better performance? Performance criteria can be based on general user experience.

2026-01-09 19:38:36 CET

I believe providing economic incentives to relay operators is essential for the nostr ecosystem, and among the possible approaches, attaching e-cash when publishing events seems optimal to me. I’ve been skeptical of subscription-based payment models, and more importantly, with standards like NIP-17, users send their DMs not from their main pubkey but a temporary one—making subscription models fundamentally incompatible.
Recently, I noticed increasing spam accumulating on my personal relay, which became quite unpleasant. I thought there must already be a NIP addressing this, so I went looking—but found nothing. Hmm? I decided to try implementing a solution myself, even if just according to my own idea. But immediately after starting, I understood why such a standard hasn’t emerged yet.
It turned out to be too complicated. When publishing an event, devs familiar with the nostr ecosystem typically use an outbox model, publishing across different sets of relays dynamically. However, most clients don’t publish to individual relays one by one, but broadcast to all target relays via nostr-tools(or something like that). This means if we want to attach e-cash to a *specific relay only*, implementation complexity spikes dramatically.
Moreover, what happens if the relay’s price changes? How should the relay behave if it receives the same event again (e.g., due to a re-synchronization or backfill)? Should already-sent e-cash be refunded, and if so, how? And if refunded, must that e-cash be redeemable again? When you dig into all these edge cases one by one, the feasibility of such a system becomes questionable.
The most practical implementation so far might be keychat approach, but even that was designed for a messaging app rather than a social network—and still doesn’t integrate well with the idea of an inbox-relay model for DMs.

2026-01-09 05:56:38 CET

- reply

you can use ollama in vscodium via cline (an vscode extension)

2026-01-08 01:26:56 CET

- reply

So at first, I thought that when I left a comment, the inbox relay of the tagged person had a paid relay, which is why that popup appeared.

2026-01-08 01:24:30 CET

- reply

That's weird. Even though I'm not using those relays (neither inbox nor outbox), I occasionally get a payment request popup on Amethyst.
PS. Is that popup message following some standard NIP related to the monetization process of relays? For example, receiving a response like "refused: payment required," and then displaying a popup to the user showing something like "this relay requires $X per month," with pricing information included in tags or similar structures?