hoppe2

Public Key

npub1pt4qwkcpp76et45pfatrxqywsuxh0gky84xa592yapesuqye29zql4eera

Profile Code

nprofile1qqsq46s8tvqsldv466q5743nqz8gwrth5tzr6nw6z4zwsucwqzv4z3qpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dss6np3a

Publishing to

relay.damus.io

nos.lol

Author Public Key

npub1pt4qwkcpp76et45pfatrxqywsuxh0gky84xa592yapesuqye29zql4eera

Show more details

Last Notes

2026-07-15 00:43:16 GMT

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-09 03:49:18 GMT

- 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 17:08:03 GMT

- 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 16:52:57 GMT

- 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 00:17:13 GMT

- reply

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

2026-06-30 07:09:13 GMT

- 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-13 06:58:11 GMT

- 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 13:29:27 GMT

- 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 11:29:09 GMT

- 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 03:49:48 GMT

- 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-21 00:47:41 GMT

- 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 00:26:14 GMT

- 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-13 00:29:19 GMT

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 00:33:39 GMT

- reply

and do not enable auto-update

2026-05-05 03:51:39 GMT

- 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 02:47:55 GMT

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-28 00:44:48 GMT

- 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 15:11:25 GMT

- 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 10:46:09 GMT

@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-13 13:19:50 GMT

- 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-03-20 00:10:42 GMT

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 12:50:37 GMT

- reply

make sense

2026-03-19 00:43:00 GMT

- reply

Great!!

2026-03-18 23:15:38 GMT

- 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 15:17:44 GMT

- 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 14:02:24 GMT

- 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 00:54:14 GMT

- 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 00:25:24 GMT

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 00:14:17 GMT

- reply

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

2026-03-13 00:33:45 GMT

- 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 00:34:24 GMT

- 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 08:01:27 GMT

- 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-23 23:49:55 GMT

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 00:43:06 GMT

- reply

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

2026-02-08 06:58:53 GMT

- 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 05:39:06 GMT

- 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 01:53:40 GMT

- 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 01:47:24 GMT

- 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 11:53:09 GMT

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 01:41:46 GMT

- 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 00:46:18 GMT

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 00:41:12 GMT

- 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 00:31:01 GMT

- 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 10:42:20 GMT

- 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 18:38:36 GMT

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 04:56:38 GMT

- reply

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

2026-01-08 00:26:56 GMT

- 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 00:24:30 GMT

- 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?

2025-12-29 23:16:13 GMT

- reply

The one and only thing you realize the more you study history is that people learn absolutely nothing from history.

2025-12-29 03:08:49 GMT

- reply

I think providing Relay operators with some form of economic incentive is essential for a sustainable, decentralized communication ecosystem, and attaching ecash to messages seems like the most sensible solution. I'm not sure if users will accept it, though...

2025-12-24 00:31:32 GMT

- reply

When an individual has, in any way, accepted or validated a statist system, they cannot entirely disclaim responsibility for its outcomes. As thinkers of the Austrian School have long emphasized, such systems operate inevitably through coercion, privilege, and the suppression of spontaneous order—regardless of which faction happens to hold office. It’s therefore ironic when people celebrate the targeting of those they dislike, only to express shock when the machinery turns against others. If, after recognizing this pattern, one still believes the highest priority is preventing a particular party from gaining office, then of course they would support another—even if it means endorsing the very structure they claim to oppose. Haha.

2025-12-23 00:30:03 GMT

- reply

I want to change it to cln, but I hate to close the channel that's already open, so I can't bring myself to do it

2025-12-23 00:26:59 GMT

- reply

I never realized NIP-17 was this vulnerable to gaslighting—I thought scale was its only weakness. This definitely shifts the conversation toward whether Nostr needs an MLS-style approach for secure groups.

2025-12-22 16:23:53 GMT

- reply

I'm living in this country, and it's fucking terrible. Especially in Korea, there's a personal identification ID for everyone, and real-name verification is mandatory for virtually all financial systems. Since this is mostly done through phone, avoiding it is nearly impossible.
I'm only fortunate because I've already moved all my assets into Bitcoin and physical gold/silver, but my monthly salary still comes in fiat currency... I really need to figure out a way to quickly switch to earning Bitcoin as income, but I can't find a feasible solution yet. Alternatively, I should make as much money as I need to live on as fast as possible and flee to a country with a lower cost of living. Honestly, the whole situation here is just utterly fucked.

2025-12-22 16:20:11 GMT

- reply

2025-12-22 00:33:37 GMT

- reply

I decided to have steak for dinner tonight.

2025-12-17 13:57:09 GMT

- reply

genius

2025-12-17 00:37:34 GMT

- reply

Just two more to find — let’s go

2025-12-11 11:41:37 GMT

- reply

You're right about that. Since this isn't a research paper, this should be enough.

2025-12-11 10:55:28 GMT

- reply

What I meant wasn’t the airport itself, but border control—there was some room for misunderstanding. Even those granted entry are forced to give up all privacy, subjected to interrogation and scrutiny by the state. And nighttime curfews in parks? That goes without saying. I could keep listing such examples forever.
In a society where property rights are truly protected, pursuing one’s own interests without force isn’t flawless—but it is by far the best system we have. Nothing beats it. You might cite cases where profit-seeking leads to neglect of safety or fairness, but even those cases are almost always driven by government coercion. Take the most tragic reality of our time: children being killed in bombings during war—there’s a clear, horrifying example. Who’s most responsible for enabling such horrors? Right. The government.

2025-12-11 09:49:31 GMT

- reply

The landowner of private property will exert every effort to attract people to their land in order to gain profit—voluntarily, not because they're forced to. This is far more sustainable. In contrast, public spaces, which are supposed to be freely accessible, often end up being even more restrictive. Just go to an airport once, and you'll understand.

2025-12-11 08:55:48 GMT

- reply

Expression of strong support for freedom of speech typically leads to counterarguments like the cases mentioned by @npub1000…vwqk and @npub1t3g…l5g4 — situations which most people, including the original poster, would find unacceptable (for example, threatening or sexually harassing someone's children). Faced with such cases, the original argument usually retreats, resulting in the conclusion that completely unrestricted free speech is impossible. In my view, this conclusion generally stems from profoundly statist biases.
Specifically, it arises from the illusion that vice can only be corrected through the coercive force of a violent monopoly — the state.
However, genuine freedom of speech can only be consistently and logically achieved through rigorous defense of private property rights. Notice how problematic examples are almost always set in "public spaces" — but the very existence of such spaces is the root of the problem.
Imagine a fully free society. In this world, there is no such thing as a "public space." Every piece of land is privately owned, and access is granted solely at the owner's discretion. In such a scenario, offensive or insulting speech? There would be no need for laws restricting speech. Instead, basic common courtesy — polite requests to refrain from offensive remarks — would suffice. If someone ignores the landowner's request, they become, by definition, a trespasser. They will then be treated as an unlawful intruder — subject to removal or other responses appropriate to illegal entry on private property. Ta-da! No law restricting freedom of speech, yet vice is corrected?
We must abandon the illusion that only state violence can correct immoral behavior.

2025-12-11 00:25:57 GMT

- reply

which client support quote zap event?

2025-12-03 16:45:13 GMT

- reply

#nevent1q…9275
I have a question for a hardcore Bitcoiner: what are your thoughts on the issue linked here? If you look at my history, you’ll see that I’m not trying to troll or start an argument—I am asking out of genuine curiosity.
I consider you to be one of the most influential Bitcoiners on Nostr (unlike those who just treat Bitcoin as a "get rich quick" scheme based on hearsay). I’m asking you specifically because I believe you have likely given serious thought to problems like this.
It seems inevitable that in the future, the mempool will be flooded with just channel-opening transactions. When that day comes, and ordinary people can no longer afford the fees for even a single on-chain transaction, how will they be able to own Bitcoin?
If there is no way for them to do so, wouldn't that essentially negate Bitcoin’s greatest advantage? If there is a solution, what is it?
Oh, of course. Regardless of the ultimate debate over whether gold or Bitcoin is the 'true money' that will endure longer, I do agree with you that those selling Bitcoin now to buy gold and silver will soon regret it. But just to be clear, my question isn't about the near future.

2025-11-28 11:57:36 GMT

Snorkeling with sharks in the Maldives https://blossom.primal.net/2d16014efb7d57eb2f04563d3653b65a738e812c57fbe88245659014f3cf0681.mp4

2025-11-27 10:59:12 GMT

- reply

Are there any technologies that can remotely disable surveillance cameras? Something like a miniaturized EMP or similar?

2025-11-27 03:49:47 GMT

- reply

I think the true final boss might be IP addressing and the routing system itself.

2025-11-24 13:32:40 GMT

Being at a resort with a poor internet connection has made the performance differences between Nostr clients strikingly obvious. nosotros seems to be the best. Of course, this might require a deduction based on how well it adheres to the Outbox model, so a simple comparison based on initial loading speed alone might not be a fair assessment.

Originally, the top performer in this area was @nprofile…wywf but it slowed down a bit after the Outbox model update a few months ago.
In reality, we can't really know how perfectly nostr clients construct the feed using the Outbox model. Since most people designate at least one large, popular relay as their outbox relay, it would be difficult to notice if a client doesn't actually support the Outbox model.
As a side note, @nprofile…mh2x android was the only one that worked even when the internet connection was completely severed. This must be due to it fetching the feed from a local database rather than a relay, building the feed, and continuing to accumulate data in the local DB in the background. It's fast, too.

2025-11-21 00:55:12 GMT

- reply

"when a member sends a group message, it essentially sends a one-to-one message to the other members. Therefore, the encryption security of small groups is almost equivalent to that of one-to-one chats, but the number of members it can support is limited."
Because of this, some Nostr clients seem to have trouble distinguishing whether a message delivered to me is from a small group chat or a 1-to-1 DM. I've been switching between so many different clients that I've forgotten which ones they were.

2025-11-17 00:24:25 GMT

Questions about @npub1h0u…rwx8
* Direct Message Sorting: When I receive DMs through Keychat, the messages are often out of order, not sorted by the correct chronological time. This seems to be due to sorting by the randomly chosen time for metadata protection, following the NIP-17 standard. However, doesn't the encrypted data inside the seal contain the true timestamp of when the message was written?
* Duplicate DMs: The DMs I receive are consistently displayed twice, as duplicates. I have no idea why this is happening.
* Signal Protocol and NIP-17: I understand that Keychat uses the Signal Protocol, yet I still receive DMs from clients that do not support it. Does this mean that while sending messages uses the Signal Protocol, receiving messages supports both NIP-17 and the Signal Protocol?
* Transaction Fees and Refunds: I saw in the documentation that sending a message (adopting a "postal system" model) consumes 1 sat via ecash. However, it seems to be immediately refunded. What is the reason for this refund? Could it be because I sent a DM to someone using a client that doesn't support the Signal Protocol, and the message therefore couldn't be delivered? In other words, does Keychat have a system to refund the sat if the message delivery fails?

2025-11-15 13:38:37 GMT

There is a single reason why I cannot be completely positive about the future of Bitcoin. It's the scalability issue, and many people would say the Lightning Network is the answer. Of course, I've realized its usefulness by actually running a node, but I'm not fully convinced that it will work perfectly even when Bitcoin is used as the true money itself in the future.
This is because an on-chain transaction is still required to open a channel, and Bitcoin's block size is fixed at 1 megabyte at the consensus level.
I agree that the proper way to solve the scaling problem is through the Lightning Network, after solving the transaction malleability issue with SegWit, rather than increasing the block size. Increasing the block size requires a hard fork, is not a fundamental solution, and makes it increasingly difficult for individuals to run a node.
However, can the Lightning Network be a fundamental solution? If the population continues to grow while Bitcoin's supply and block size are fixed, won't there inevitably come a day when people cannot afford the fee for even a single transaction, even if they work their whole lives? Even if everything is processed through Lightning, at least as many channel opening transactions as the number of people being born are needed, and that number will only continue to increase, right?
This is a mathematically foreseen problem if we accept the assumption that the population will grow, not just a curse from pessimistic critics driven by jealousy. Consequently, won't the common people be unable to achieve true ownership in the genuine sense of the word?
I'm curious about the stance of nostr user on this. The positions I've encountered so far are as follows, and I can't agree with any of them:
* Solve it with a hard fork. -> This is the stupidest solution. How is this different from Bitcoin Cash?
* The population won't grow that much. -> Is the future of humanity that pessimistic?
* Ownership can be managed in a form like ecash. -> Does this mean complete ownership is solely the privilege of the rich and earlier generations? Doesn't this negate Bitcoin's greatest advantage?
* A solution will eventually emerge that guarantees complete ownership and is affordable for common people, no matter how large the population. -> Isn't this overly optimistic?
This is the reason why, even after understanding the Lightning Network, I bought Bitcoin with all the money I had left, and continue to buy Bitcoin with my salary (excluding living expenses), but I haven't been able to go all-in by selling my gold. Is there a solution I don't know about? If someone knows, please let me know.

2025-11-07 23:24:48 GMT

- reply

Hello. Thanks for the test. You are Megalithic.me, correct? I was really helped by your documentation when setting up the node initially, so it's good to hear from you. Anyway, since the server hosting my Lightning address is run by an amateur, the connection is a bit unstable. It was turned off and on again yesterday while some work was being done. It's strange because by the time you replied, the work should have been finished. I tested sending from my separate wallet just now, and it did go through.
However, this has happened before. For example, transfers to my address from Wallet of Satoshi didn't work. I don't know the reason. When I inquired with them, I received a response suggesting it might be because my server supports too limited TLS options, but looking at my Nginx configuration, that doesn't seem to be the case. Anyway, it's a mystery. I'm starting to think it might be best to just leave the operation to a professional, as you advised. I plan to do so if I see a few more failures.

2025-11-07 10:47:32 GMT

Just in case anyone doesn't know, your follow list is completely public data on Nostr, and due to how decentralized SNS works, it is the type of data that is rarely but is recommended to be broadcast to almost all relays.
And this information is utilized for various purposes. The most common use is to act as a filter to screen out unpleasant spam. Since Nostr has no administrators (censors), a separate mechanism is needed to filter spam, and it's typically used to make an assumption like: posts by people who are followed by the people I follow are probably not spam, and so on.
If you still see an unpleasant image despite such filtering, it means someone in your follow list is following the spammer who posted that unpleasant image, which naturally leads to users trying to find out who that person is.
Of course, I know that following someone doesn't necessarily mean agreement, support, or affection for that person, but your taste can be questioned, so I hope you manage your follow list with a bit more caution.
If you feel those around you don't know this, please boost this so they can become aware without feeling awkward. Lol.
I should also check my own follow list to see if I've accidentally followed anyone

2025-11-07 02:00:49 GMT

#foodstr
https://npub1pt4qwkcpp76et45pfatrxqywsuxh0gky84xa592yapesuqye29zql4eera.blossom.band/0e30c53edd962702e32057d63f75f49e9a454d9806e5974f5703c1c955a59cd4.jpg

2025-11-03 03:17:17 GMT

- reply

I lost it :( My precious 5 sats (7 including fees) are gone lol.

2025-11-02 13:54:42 GMT

Today, I finished migrating the translation service for #jumble to a self-hosted setup. I initially looked into LibreTranslate, as it was an available option, and discovered it's an open-source translation model. However, after testing it, the quality was significantly lower than Jumble's official translation service—to the point of being unusable.
Then, I remembered that the translation performance from Ollama, which I use regularly, is quite impressive. So, I built a simple adapter that mimics the LibreTranslate API but delegates the actual translation work to Gemma3:27B running via Ollama. It's working perfectly.

2025-11-01 07:59:14 GMT

- reply

Most people don't really understand what inflation actually means. In that state, nothing you say will make any difference.

2025-10-30 01:50:49 GMT

- reply

If on-chain transactions are inconvenient, they can use Lightning channels; if channel liquidity management is inconvenient, they can run a Chashu mint — so if someone still insists on creating an alt, it means they have some other agenda.

2025-10-30 01:06:27 GMT

- reply

Feeds from individuals following thousands of different pubkeys are fundamentally impossible to paginate in a true sense, and I see this as the biggest performance issue with nostr. That's why most people say the most practical solution is for each person to keep their following list at a reasonable size.
However, from my past experience studying Neo4j’s internal structure, I realized that structural support is actually possible for paginating notes from arbitrary lists of pubkeys in reverse chronological order. Unlike current typical relay architectures—where we have to fetch a batch of events per pubkey, then merge and re-sort them—it felt like Neo4j’s structure could directly query only the exact amount of data needed for a given limit and offset, making the operation much more efficient.
But is this just theoretical? Would it actually not be that much faster in practice?

2025-10-28 06:51:13 GMT

- reply

The most important reason why Bitcoin is great is that it operates independently of traditional systems, functioning regardless of what laws or politicians do. People who keep talking about politicians needing to "do something" or worrying about what happens "if politicians regulate it" clearly still don't understand what Bitcoin is.

2025-10-25 10:07:51 GMT

I've been using amethyst and amber together, and even though I haven't received any DMs, I keep getting requests to decrypt something. Does anyone know what this is?
#asknostr

2025-10-23 14:30:31 GMT

- reply

Even more annoying than websites asking me to accept cookies is the government creating stupid legal regulations that force those ridiculous cookie warnings to keep popping up.

2025-10-13 01:09:19 GMT

I learned about the ketogenic diet and discovered bulletproof coffee. I made it, and it's really delicious! Most importantly, it keeps me full until lunch when I have it in the morning.
https://cdn.nostrcheck.me/640432e57eb602031b79d70f09e7be069b0fc227da55c9a0ff5dbcc35791e441.webp

2025-10-07 09:16:50 GMT

I'm using a MacBook Pro with M4 Pro Apple chip and 48GB of RAM to run a local LLM via Ollama. I'm wondering which model would be most suitable. When I ran Qwen3:30B, memory usage went up to about 31GB, so I think I could probably handle a slightly stronger model, but I'm not sure exactly which one to pick because there are so many options.
#devstr #asknostr

2025-09-26 14:00:00 GMT

I'm watching several videos about health and diet, and I'm more shocked than when I encountered Bitcoin and studied money and economics. If this is true, the corruption of modern medicine is beyond the malice of the Federal Reserve in economics. The problem is, unlike economics, I don't have the ability to verify the claims made about medicine and diet.

2025-09-25 14:18:08 GMT

#nevent1q…w9gj
Here’s why you shouldn’t ask AI about finance or cryptography, and most notably, the technical aspects of Bitcoin. I asked because it didn't make sense to me, and the AI responded with a lengthy and complex explanation. If you just go along with it, it sounds plausible, but no matter how much I thought about it, the answer didn't seem right. Eventually, I asked someone knowledgeable, and they said there probably wasn't a special reason for it. It was just one of Bitcoin's many oddities that was originally designed that way and now can't be changed. If these AI systems don’t know, they should just say so. Instead, even when they don't know, they throw out all these sophisticated words, making it sound convincing.

2025-09-25 13:50:59 GMT

- reply

I asked that person about the question, and he also didn't think there was any particular reason it had to be that way. It seems likely to be one of those things in Bitcoin’s history that weren't technically necessary, but were simply implemented by Satoshi that way—and now it can't really be changed, so it's just left as-is. Looks like my guess was right.

2025-09-24 20:06:18 GMT

- reply

Don’t rush. I still haven’t gotten an answer, lol.

2025-09-23 23:09:14 GMT

- reply

Right, I’ll follow your suggestion and ask by email. The blog looks very professional, and I think he’ll be able to answer my question well. Thanks for recommending

2025-09-23 15:48:52 GMT

- reply

I read the blog post you linked, but I still don't understand. In the attached screenshot, the blog states that the reason for putting the previous locking script in the empty signature space is to indicate that we recognize the original locking script. Does that make sense? It's not hidden information; anyone can find it since the txid and vout are specified.
https://cdn.nostrcheck.me/ebc5fb4ccd63e238945f8877738de1f0f16959017feea3dc7c62c2569bb64596.webp
https://cdn.nostrcheck.me/cb5a012f01d420be5284a75ee2ff66c310b26abe4028ce7ce50ce3d7b080f0af.webp

2025-09-23 00:45:12 GMT

When signing a Bitcoin transaction, there's a space within the transaction data reserved for the signature itself. Obviously, since the signature hasn't been created yet, we can't fill in the actual signature at this point—we create it later and insert it.
The issue is that instead of just leaving this space empty, it's filled in with the locking script (scriptPubKey) of the UTXO being spent. Does anyone know why it's done this way?
Is there some vulnerability that would arise if we left it blank when signing, or did Satoshi just design it this way arbitrarily, and now it's too late to change?
I asked an AI, but either I asked poorly or it just gave me nonsense answers.
#asknostr #devstr #bitcoin

2025-09-22 10:13:42 GMT

I've been wondering why many Nostr web apps that support NIP-46 "Bunker Login" only seem to support the case where the bunker initiates the connection. When a user isn't logged in, there's no easy way to transfer the token created by the bunker (unless you use an external messenger or email, which is a clunky solution).
It seems much more convenient for the client to create the token, display it as a QR code, and have the signer(@npub1am3…xrv7) scan it.
I recently learned while working on Jumble's code that the reason for this was a lack of support in nostr-tools for the client-initiated token creation method. Now that nostr-tools supports this feature, supporting the login flow to allow the client to create and send the token to the bunker would make the entire process much smoother.

2025-09-20 07:46:51 GMT

- reply

she will regret it within ten years at the latest. If it's sooner, it could be within five years

2025-09-18 23:12:17 GMT

- reply

I don't even understand why this is newsworthy. Maybe for normies, fine—but on Nostr? Anyone who understands what Bitcoin is and what a nation-state is should immediately see that the idea of a "Bitcoin president" is contradictory, and that it makes no sense for any president to "support" Bitcoin. There's nothing surprising when it's inevitably revealed to be false, and more importantly, they should know that we don't even need any president to support Bitcoin.

2025-09-18 23:07:23 GMT

This is true. If you believe that some kind of taxation is "necessary," or at least a necessary evil, then it can be said that Bitcoin will never be used completely freely as money. Of course, outright banning Bitcoin is not an easy task even for governments. But there's a much easier way. Rather than tampering with the internet, governments could simply make it illegal not to issue (government-reportable) receipts when someone pays via Bitcoin (or cash, gold, silver—anything enabling payments that don't leave a trace on the state's surveillance network). Then offer rewards for reporting or informing on others, and you'll have self-righteous Gestapo-like citizens scurrying around, eager to snitch, believing they're contributing to a just society. The result would be a society where citizens monitor other citizens.
If you truly understand what fiat money is, then you can understand what kind of entity a government is that forces us to use it—and understanding that allows you to grasp what taxes really are. Anyone who believes taxes and the state are in some way necessary thereby contributes to building a surveillance and control society.
There are even self-proclaimed "Bitcoiners" who loudly cry out for freedom when the government obstructs them, but cheer when it tramples on those they dislike; people who shout that inflation is theft when criticizing Democrats, yet stay silent when Republicans engage in money printing. Isn't that amusing?
#nevent1q…d2ar

2025-09-18 22:39:23 GMT

- reply

https://www.youtube.com/watch?v=Hzv9WuqIzA0
I decided to just understand the big picture at this level.

2025-09-18 04:47:49 GMT

I've muted my phone, but alarms and other sounds still go off. This whole system of separate volume controls for different categories is completely pointless. Who actually manages their sound settings that way? 'Mute' should mean MUTE for everything. It's a completely idiotic feature.

2025-09-17 10:02:19 GMT

- reply

Isn't there someone who would create something to effectively destroy surveillance cameras remotely? Haha

2025-09-14 03:17:55 GMT

- reply

I haven't seen anything outside of Nostr that treats cryptographic keys themselves as identity, so I don't really know about others — but don't others sign follows with their private keys? Unless a system doesn't treat the public key itself as the identity at all, I can't imagine a design where follows aren't signed with the corresponding private key.

2025-09-12 00:36:08 GMT

- reply

Well, if I'm wrong, that's even better—so whatever.