It could still be many things.
Exchanges and other regular transaction entities (to allow account withdrawals), or OpenTimestamps, don’t have much choice. They grind to a halt.
However people who want to open Lightning channels may way for it to ease.
And people may use lightning instead of Bitcoin to pay while fees are high.
Anyone planning on consolidating will defer as largely no rush.
Likely a typical lag after a few spike, while people and businesses adjust their transaction schedules and usage down.
It’s expensive, however it’s still pretty interesting to see how easy it is to cause mempool related transaction delays for Bitcoin. Overall it’s just growing pains and a catalyst for innovation and adoption in other areas like lightning.
My primary hurdle with straight value for value (defined as: user chosen amounts and typically in more frequent smaller payments) is there is a difficulty in determining the market reference price as a payer - basically what something costs without similar reference products/items.
You often have no reference point and don’t want to over pay or under pay - which creates friction. You also lack context around what the amount you choose means to the payee - patron subscriber goals help materialise what future support levels mean to a creator for example.
Sometimes you could calculate based on how much of your time was saved. That doesn’t really work for entertainment content.
Ultimately I think peer to peer payments to more directly support causes, communities, and individuals will grow significantly - perhaps just with more structure than ad-hoc zaps.
Last I checked, the mempool typically has a max MB (in memory) size cap. When full, it drops the lowest sat/vB transactions. Normally transactions get dropped after two weeks of no confirmation, in the case the mempool never overflows. The mempool also rejects dust (too smaller transactions), as basically it can be a spam attack vector.
The fees paid are typically an urgency calculation. If your transaction is less urgent, and still above the current purge sat/vB limits, then you may just have to wait longer.
Hopefully it’s a sign of inscribers running out of their VC funds, shitcoin bubble, or trust fund depleting. More likely it’s just a breather.. there is no urgency in inscribing more crap that you can’t sell and paying a higher fee to get it quicker. Rate limiting your transactions makes it cheaper.
I think Nostr will evolve to have a mix between a badge system and a DNS Text record where you can cross-auth/link accounts programmatically with fast/easy verification. Kind of like keybase.
It will likely end up being a mix of push and pull - where some services like twitter will never help verify your Nostr account, while some may support an easy way to link your profiles - again the key being fast and easy to verify from both sides, as each side could be deceptive.
TLDR: they are making usernames/handles globally unique (previously case insensitive and appended with 4+ digit number). Display names can be anything. Usernames and handles only really used to connect or differentiate/compare profiles.
Effectively in a Nostr world, pubkeys are too hard to share, use a NIP-05 as handle, (Display) Name yourself whatever.
Maybe “Nostr Username” or “Nostr Handle” are a better lexicons for NIP05 identifiers. It helps take away the ‘verified/verification’ misunderstanding. I guess it’s possible to read-only login using your nip05 as a username too.
#[0] my NostrGraph relay’s status in Damus has been flapping. Only started the last couple weeks or so. No changes my end, and server data seems fine.
Anything I should check? Maybe rate limiting or something is getting triggered.
Holy shit. This game nails the problem with moderation. Literally give it a go if you think moderation works. You’ll see how it’s near impossible to do quickly, it’s always biased, 70% accuracy gets applauded, you regularly make decisions (on behalf of everyone else) without any real way to know, decisions are highly contextual or location based - like legality, and so on.
And don’t forget moderators have KPIs today based on number of items reviewed.. they are literally paid more to think the exact same as each other and moderate with the same action (as many moderations are sent to multiple people to check consensus and that people are working and not blindly swiping/clicking).
nostr:note1twphe832esj20kc99n77prvufw2vnm0399gv546tgaaxvvttuyzq65r0y3 
Having been prototyping a Nostr payed lightning CDN, I’m circling back to read up on LSAT again.
Effectively it leverages the 402 Payment Required HTTP response, and a WWW-Authentication header (exactly my approach) and acts as a reverse proxy in front of a service. It doesn’t require private key auth, which seems great, but you also need to store state for a macaroon and a payment hash (which also allows sharing). LSAT does enable fine grain pay as you go payment models - perhaps interesting for Nostr services.
LSAT doesn’t seem to have really taken off since 2020. Maybe Nostr’s zap and lightning adoption could help growth. #[0] just released this LSAT demo as well, with split payments. https://weather-lightning.bumi17.repl.co
Anyway, I think it’s worth exploring more and understanding what options and approaches we have, that may be useful as part of Nostr functionality and economy.
#[1] are you keen to include something like this in your NDK? It likely doesn’t need to be a separate project/lib.
CC #[2]
Nostr needs your best ideas.
Reply to this post with your best ideas for Nostr - client features or relay features, mini-apps, ways to attract more users, or anything that will move Nostr to the next level.
Best idea wins a Ticket to Bitcoin 2023 Conference in Miami next week? ($949 value)
We will announce a winner on Sunday. You are on your own for travel and lodging.
#devstr https://devstr.org
We need better community building tools and apps. Right now someone’s Nostr community is their followers - however the most enthusiastic followers want to be part of a core group.
Today they have patreon, telegram, discord, YouTube subscriptions, etc - all off shoots of more personal communities, more intimate discussions and often a safer place to share. Some paid groups and some open membership. It’s the difference between “follow me on” Twitter, and “join our” discord/telegram/whatever.
It could be a private white label relays service, or a multi-channel group workspace. A mix of posts and chat. Ideally content can be persisted without worry. Likely some moderation options.
Basically empower communities builders and members to come together on a Nostr foundational network. Network effects will bring the next 10 million to Nostr.
PS. I realise this is more of a concept that a specific idea - however getting there can take many paths.
I don’t see why we can’t just have an on-boarding experience where people select a few topics they care about or don’t care about. If they unselect Bitcoin, it can just filter out the 3-4 variants of it being mentioned.
Another good example is to filter #NSFW, or perhaps content warning events.
They can always go to filters and change them in future.
The only UX weird part is it’s kind of reversing today.. you select topics you don’t want to see.. normally you select what you want to see.
We don’t need this at the relay level - at least ignoring data consumption.
I’m still surprised we don’t have more universal in-client regex filtering of Event content. We likely need an encoding we can share them with too.
Telegram played a big part in information sharing and collaboration during Covid. Being pseudonymous and having a pretty strong adversity to banning people or channels made it very popular.
The main issue I found is the opposing mainstream messages ironically became largely propaganda and mistruth based. You could find people who disbelieved the government and Pharma lies - however it was hard to believe anything in the chat, as it was full of angry people who would say anything to try counter the government’s lies.
And the people who should have been speaking out like doctors and nurses were threatened with their jobs. It’s hard to whistleblow in that case without being public about your identities.
Hopefully we can do better next time… it’s all pretty complex.
I’ve updated my rust Lightning webhook library example code for both BTCPay and LNbits - you literally can set some ENV vars, uncomment some code, and set your desired SQL payment code. Then you just create your invoices with metadata like a pubkey, enable web hooks, and you’re 😎.
God damn they are deceptive in their wording. Let’s sound the the best and only product, yet constantly use subtext to subtly scope claims into tight niche.
“It’s the only phone, _made by Google_, that”
“It’s the only foldable, _engineered by Google_, that”
“It’s the highest rating X, _in it’s class_, …”
This is the way
Twitter launches encrypted DMs behind a paywall
https://www.theverge.com/2023/5/10/23719153/twitter-encrypted-dms-paid-verified-feature
I’d use a queue for inbound events and then you can pull from that queue using a worker type flow and then add the event id to a set, after doing a membership test to see if you’ve already processed the event.
Alternatively, since the set will grow in size forever (between restarts), you’ll either need to persist the set data (like Redis) or use a LRU cache or something like a ring buffer. Or perhaps a bloom filter if an occasional false positive is ok.
It all kind of depends during what time frame do you expect the duplicate events. Over an hour window, or days, or months, etc. Is reprocessing an event forbidden. And how many events or relay sources.