melvincarvalho
Melvin Carvalho

https://melvincarvalho.com/

Mathematician and Web Developer

Public Key

npub1melv683fw6n2mvhl5h6dhqd8mqfv3wmxnz4qph83ua4dk4006ezsrt5c24

NIP-05 Address

melvin@nostr.me

NIP-57 Address

melvincarvalho@ln.tips

Profile Code

nprofile1qqsdulkdrc5hdf4dktl6taxmsxnasykghdnf32sqmnc7w6km2hhav3gppemhxue69uhkummn9ekx7mp0dtyd74

Publishing to

nos.lol

Author Public Key

npub1melv683fw6n2mvhl5h6dhqd8mqfv3wmxnz4qph83ua4dk4006ezsrt5c24

Show more details

Last Notes

2024-09-16 09:24:14

In Bitcoin and Nostr, a false dilemma (ake either/or fallacy) often divides people: either adoption must reach millions, or it’s considered a failure. This mindset is like saying a small plant must become a massive tree overnight, or it’s not worth growing at all.
Cypherpunks like Satoshi ignored these extremes. They focused on writing code and solving problems, knowing growth happens step by step. Polarization halts progress—pragmatic solutions nurture it.
https://en.wikipedia.org/wiki/False_dilemma

2024-09-12 10:57:18

2024-09-06 12:42:24

- reply

Alex helped me with profile:
https://drive.google.com/file/d/1O_jmjQnc0-a-XPSiJhN7xuNE_LPKsTng/view?usp=sharing
If you download this file you should be able to do something like
cat ditto-kind0.jsonl | deno task db:import
inside the /opt/ditto directory of your server to import a bunch of profiles
This is a workaround until I improve Ditto to pull this data automatically from relays

2024-09-04 08:42:58

I have liked this interview, for a long time, and often think back to it.
"I usually don’t speak on behalf of myself. I don’t fight for myself. That was the one time that I did. I don’t know if it worked. No one really cared." -- Jack
I think some people care. I think some people will fight for Jack, or with Jack.
https://www.rollingstone.com/culture/culture-features/twitter-ceo-jack-dorsey-rolling-stone-interview-782298/

2024-09-04 08:37:50

100M Token Context Windows
https://magic.dev/blog/100m-token-context-windows

2024-09-03 13:11:17

- reply

Thanks for the clarification. Its a worry that the privacy oriented OSS project says nothing about the privacy invasive company and closed source project. I've seen this movie too many times.
I remember now I went to a fedimint workshop. The speaker asked how to send keys to one another, and I said, from the audience "Nostr".
Fedimint has too many flags for me to blindly trust it.
I hope it works though, and the docs are interesting, and could easily be done with the *existing* relay infrastructure with a 2/3rds honest majority. Rather than having to run new software, learn it, audit it etc.
"One such protocol is AlephBFT. We will mainly use it as a reference for BFT consensus properties but note that similar but more efficient ones exist (most notably Dumbo and hybrids built on top of it)."
https://fedimint.org/docs/MiniMintDetails/Consensus

2024-09-03 11:32:23

- reply

Before nostr, I founded and was first chair of the W3C Solid Community Group. I always wanted to build Solid and personal storage to work together with nostr. In we made pub/sub websockets in solid before Nostr did it. I spoke to Alex and I am hopeful we can get some Solid ideas to work with ditto. Then we have Nostr + Ditto + Solid to be better than ActivityPods, and a whole scalable financial layer can be built on top of that.

2024-09-03 10:21:11

If you think nostr is good, #ditto is going to blow your mind.
What has been achieved, with simple text strings, and small relays, is incredible.
When devs get all of that, PLUS the full power of structured JSON, a massively scalable architecture, and permissionles dev, literally anything will become possible!

2024-09-03 09:50:43

- reply

Good catch! Fixed!

2024-09-03 09:45:29

- reply

Great!

2024-09-03 09:41:37

- reply

https://play-grounds.github.io/ditto/?user=stu@poster.place

2024-09-03 09:36:57

- reply

I have tried adding:
object-fit: cover;
"CSS property ensures that an image fills its container while maintaining its aspect ratio, cropping any overflow to prevent distortion."
Maybe it helps a tiny bit? I cant really see much difference.

2024-09-03 09:15:14

- reply

Ditto is a new scalable architecture built on nostr. It has both relay string API and an interoperable JSON API. In this case, I am building new small (micro) apps, which are self contained, on the ditto API. I love it!

2024-09-03 09:06:45

#ditto micro app can now pull in multiple profiles
https://play-grounds.github.io/ditto/?user=alex@gleasonator.dev
https://image.nostr.build/92aab4a8ea68a4e65e813385c2c26b630c1e430967a8a2a6c5fe49c262d4a70d.jpg

2024-09-03 08:37:41

- reply

Not sure I trust fedimint to be honest. They claim to be a privacy solution yet have spyware on their high profile new launched site. Nevertheless, I hope they are successful. I may use it one day. The principles behind can be replicated in any number of ways. Relays already exist, so they can do something useful, without needing a 3rd party spec or system, that I would have to learn and audit. End result is more choice for the end user.

2024-09-03 08:32:01

- reply

Keep going. And JavaScript is your friend ...

2024-09-03 08:25:16

My first #ditto micro app. Not much, but it's a start!
https://play-grounds.github.io/ditto/
https://image.nostr.build/31648dbeb32c81cae3505612b51edb1b6e42edee8f20d0ea97da56c54370d9a7.jpg

2024-09-03 07:55:28

- reply

Testnet coins have value. The mythology of it is to say that they dont. You cant actually wipe a testnet, any reorg will make the chain of accumulated work longer. All you can do is stop linking to it.

2024-09-03 07:51:16

- reply

Seems very similar to fedimint. But using relays, which already exist.

2024-09-03 07:46:56

- reply

Have you tried ditto yet?
https://docs.soapbox.pub/ditto/install

2024-09-03 07:43:23

- reply

🍿

2024-09-03 07:42:34

- reply

ditto
lightning
qtorrent (search)

2024-09-03 07:21:04

- reply

Running it now at https://nostr.me ... loving it so far!

2024-09-03 06:52:46

If you could create a dynamic federation of relays, with 2/3rds honest majority, it would be superior to cusodial services or mints. This should be tried on bitcoin testnet, to proof it works. And then offered as a service on nostr.

2024-09-02 19:43:22

Finally got new pc with ubuntu 24.04 working. Time for a new subkey... and to write a subkey linked data spec...

2024-09-02 19:13:34

- reply

You made me realize how much we need nostr-ld (nostr linked data) a permissionless extensible data and discovery model for notes, and other stuff.

2024-09-02 18:52:12

- reply

Good talk—it really opens people’s eyes to possibilities they might not have considered. I’ve been pushing this message for a decade, about what apps, socials, and discovery can bring to Bitcoin. But it’s only now, with Jack on board, that more folks are listening.
That said, Nostr isn’t the only way to tie metadata to keypairs. It’s one of the clunkier, less extensible options, and changing anything in the NIPs takes forever. You mentioned the existing network has utility, but I doubt there are thousands of relays—it’s probably smaller, more centralized, and less reliable.
It’s a solid message, but I don’t think Nostr is the only path forward. The censorship resistance might be overhyped too—it could just be that Nostr’s smaller than Twitter, which might also be why people still use Twitter.
The micropayment angle is strong, maybe even a holy grail use case. But Bitcoin itself isn’t used much, which is a shame since npubs are taproot addresses. We could’ve built a whole free market on a non-rigged base layer by now, but there’s nothing happening at that intersection—a missed multi-billion dollar opportunity. And honestly, there’s no real appetite for Bitcoin base layer integration with Nostr. Hope you don’t mind me pushing back a bit here—I figure you might not get much of that in the comments

2024-09-02 16:21:13

- reply

Good point. We’re still aiming at a moving target. In the next four years (the next epoch), we could see AGI emerge, which could change everything—how chains are used, how development happens, how we discuss things, and the path to ossification. Once AGI arrives, we’ll likely get used to virtual assistants that communicate on new layers, invent tech we haven’t seen yet, and do all this without needing forks.
We’ll be able to evaluate things like the mining fee auction more efficiently, figure out things like the nash equilibrium and iterative prisoners dilemma e.g. how much will a high value tx pay to get priority. All our research and explanations will get a big helping hand.
The app landscape for consensus and polling might shift too. We’ll be able to replicate the best parts of DeFi on Bitcoin, Nostr, Ditto (maybe Pear too), and we’ll be better at identifying and countering social attacks. The future could be pretty interesting, and we're not in a rush for a killer feature or osification I dont think immediately. We do want to avoid catastrophic failure vectors, and guide the project carefully through the next phase.

2024-09-02 15:31:15

- reply

Thanks, that’s helpful. My take is that we should really push single-use seals to their limits first. It’s a Layer 2 solution based on (u)txos, and like with Nostr, once people see what’s possible, they’ll get it. Single-use seals might not be perfect, but they’re likely better than Tether, and people use Tether. It’d be great if folks used and tested the tech we have before asking for more features or forks.
We’re also assuming sovereign identity is just for humans, but maybe machines will use Bitcoin more than humans. We need to see how things play out to make the right trade-offs and keep in mind the risk of catastrophic failure—like a chain split. Remember, there are vested interests that might actually want a split. A fork needs both social and technical consensus and has to be something the user base, many of whom have entrusted their life savings to this, actually wants.

2024-09-02 15:10:26

- reply

Got it, that makes sense. But we also need to see real demand for these features to justify any urgency. If there’s genuine demand, it could be shown on Liquid or Elements first, and the user base would say, 'Yes, we need this.' The same goes for a solid self-sovereign identity or trading solution—it should be tested on testnet, even with some workarounds. Creating a false sense of urgency risks dividing the community and causing a chain split, which we've already been through, and it was almost fatal. But, nobody cares when you only get shot in the ear! :)

2024-09-02 14:12:05

- reply

Glad you brought this up. We should definitely go through these points and possible solutions, though it will take some time—probably weeks or months—to cover everything in detail.
On risk, I think the biggest threat to Bitcoin is a fork and chain split, even more than a 51% attack. We've never had a 51% attack, but we've seen multiple forks and splits. Any new feature has to be worth that risk, and it should be explained clearly enough that at least 10% of users can understand it from first principles. Let's keep in mind the real dangers of a chain split.
Right now, I don’t think we’re fully using the tools we already have. I monitor testnet4 closely, and it’s clear that Bitcoin + Taproot (which ties into Nostr) isn’t being used much. Sometimes my transactions are the majority in a block.
What do you mean by critical primitives for scaling sovereignty? One trade-off could be that Nostr npubs and Taproot addresses offer sovereign ownership and property rights, whether on the base layer or something like Liquid. We’ve barely scratched the surface of using the (u)txo model for a chain of custody, like with single-use seals. A decentralized free market could be built on Bitcoin with this, but I’m not sure there’s much appetite for it right now—especially for niche use cases like vaults that no one’s really asking for.

2024-09-02 13:21:32

- reply

https://image.nostr.build/5929730a702f5bcd594ad73800aad5faca817faacf161ab80ad6551afeaf0b20.jpg

2024-09-02 13:18:02

- reply

Yes exactly. So I think there's 3 aspects
1. In any project there are those that want the status quo and those that want features
2. Bitcoin benefits from stability, and there is a social attack in dividing the community with a feature that needs a soft fork, and can cause animosity, and even a chain split
3. Devs are paid of groomed to back the fork side, as a form or, "agitation propaganda". Many will not know they are working against the project, and feel some rigeous cause.
I think that the agitation prop aspect of it is simply too valuable to the multi billion dollar rivals to bitcoin for them not to try and do it. We've had 3 civil wars so far from people that "want the best for bitcoin". So far we have won. The next battle might be harder.

2024-09-02 12:06:56

- reply

We dont need a soft fork. The features we have have barely been used. If they want OP_CTV try it out on elements and or liquid, and show there is some demand. There is of course no demand for it. The upside of a soft fork is very little for the bitcoin community. The downside is a chain split, which of course, all the enemies of bitcoin want, and will fund.

2024-09-02 11:57:05

- reply

I wasnt aware of wiki-nips or broken nips, do you have links? I'll pass them on.

2024-09-02 11:22:31

- reply

Ultra Sound Yoga Studio

2024-09-02 05:27:32

The initial version of caniuse for nostr from Marco.
https://marcodpt.github.io/nostracker/
https://image.nostr.build/42c2e3ff354fd4518173895e5140a26874ad8a75de7097b18dec7dab261b57ff.jpg

2024-09-01 23:01:40

I've been thinking a lot about what Nostr 2.0 should look like:
1. Bottom-up, permissionless dev instead of top-down control through NIPs.
2. A scalable architecture that’s interoperable, extensible, and standardized, including relays.
3. Cutting-edge features like smart widgets to compete with the latest tech trends.
4. Full npub-taproot infrastructure with financial interop, smart contracts, DAOs, markets, and naming.
5. AI integration where AI agents are first-class citizens on the network, leveraging all of the above.
#Ditto seems like the first step toward Nostr 2.0 (with shout out to nostrocket). Nostr 1.0 apps and the relay network are still going to be key, but I see the next generation starting to take shape.

2024-09-01 22:44:04

- reply

Yeah, it's tough. Nostr dev feels like a battlefield sometimes. I created NIP-17 for this exact reason, but it didn’t gain traction. Later, I developed an on-chain commitment system that could have made things smoother, but it faced resistance, particularly from those fixated on drivechain. It’s a shame because we could have had better Bitcoin integration years ago. Eventually, NIP-17 resurfaced, and with NIP-34, we managed to keep things intact with the 'let git be git' principle. Ngit now covers about 60% of what you might need, though the audit trail isn’t formalized yet. It’s a long process, and when you know your work might get shot down, it’s hard to justify the effort. Still, I’ve got it working for myself. If you’re open to a synthetic future, bots might be the way forward—no need for UX, just an API and CLI. Bots could eventually document and wrap everything into user-friendly apps. Switching from nostr-only to Ditto, which I see as nostr 2.0, could solve many of these issues—it's scalable and allows for permissionless dev, which was the goal all along.
https://gitworkshop.dev/ngit

2024-09-01 22:30:35

- reply

I've been doing this since forever. That's a big reason nostr was made.

2024-09-01 21:13:26

- reply

Which clients?

2024-09-01 21:11:04

- reply

The neglect of the nostr relay network, has been quite remarkable. Everything else was supported, but the relay network was thrown under the bus often is a quite unkind way. It is a shame because without the relay network, there would be no nostr.
Ultimately I think it's a case of "tragedy of the commons". It's never too late to help the relay network. But 80% have left and most wont come back. Let's try and do better with #ditto !

2024-09-01 20:57:57

- reply

Sad :(
Relayable.org has been downsized from its network of worldwide relays to just one in Los Angeles. This is due to a lack of financial support and large monthly hosting bills. We tried numerous times to get funding from the usual suspects but were not even sent back a denial email. So due to the ongoing costs and slowing of direct support with the price of BTC going up, the hard choice was made to downsize. Thanks to everyone who has supported and helped over the last 2 years!
- Jascha
https://relayable.org/

2024-09-01 19:53:53

#ditto allowed me to create a new nostr client, relay and website, in a weekend. Still some work to be done, but happy with the results so far.
https://nostr.me/

2024-09-01 16:39:57

- reply

Makes sense to me. There's a few of us that want to explore this further. Perhaps ditto gitlab is a good place to discuss.

2024-09-01 15:21:24

- reply

By this rationale, Satoshi was not a bitcoiner. Cmon Will, you know better than this. It's shitcoin propaganda.

2024-09-01 11:52:33

- reply

It is a relay server. But it is also an extensible scaling architecture with mobile and web front ends.

2024-09-01 11:22:58

Still a long way to go, but in half a day, I have almost got my first #ditto instance running. Still in experimentation mode for now...
https://nostr.me/timeline/global

2024-09-01 10:04:24

- reply

You may want to have a look at #ditto
https://docs.soapbox.pub/ditto/
https://image.nostr.build/ac2c1466323b11d751843029d38fe39d291d596255dec12727e6f807113817f2.jpg

2024-08-31 18:03:15

- reply

Alex has built and delivered things to millions of users before, as have I. I see good design patterns in there. I may be wrong on that, but this is the first thing I've seen in the space that I think has a really good chance of scaling. If someone else does it first, so much the better.

2024-08-31 17:58:19

- reply

Not 100% sure you need a NIP-05, because I saw it does @npub... otherwise, but I need to check that more. I dont have any issue with NIP-05 myself, it's historically been quite good and useful. However it did get changed recently.
What I like about ditto is that Alex has ideas on how to scale it, and bring things to nostr not seen before. He has also scaled other projects (to millions), so we know it's possible.
What I like about ditto is that it has caching strategies, strategies for fast content delivery, a highly polished UX. It has high interop and an architecture that I love. It is extensible and modular. With ambitious plans. A slight personal bias that I have, is that MK and Alex are both very likable, and bring alot of energy to the project too. I have trust in the team, so I am willing to throw some time at it, and have confidence, it wont be wasted effort.
Ditto also has great professional, documentation. It ticks all the boxes for me, that I've wanted for a long time.

2024-08-31 17:32:59

- reply

Similarly concept, but not quite the same. I went through a lot of details with Alex and MK, when I met them. I'm convinced that #ditto is next nevel. I do hope relay.tools will work well too. Ultimately (friendly) competition is a win for the end user.

2024-08-31 17:30:28

- reply

Finally! I've been typing this command for the last 6 months.

2024-08-31 17:28:17

- reply

yes, I used it, before I discovered ditto

2024-08-31 14:54:21

#ditto is the best kept secret on nostr. If you want to try an amazing client, go to:
https://ditto.pub/
Or install your own version using:
https://docs.soapbox.pub/ditto/install
With an elegant, scalable architecture which can handle millions of users. This was the missing piece of the puzzle that nostr has needed.
https://m.primal.net/KXNT.png

2024-08-31 14:41:54

A good reason to switch to #ditto as a client is that it has the a first class account management UX. While on some clients its hard to even find the logout button. Ditto makes it easy to use, even with nsecs. I hear good things about nostrudel too, but I have not tested the latest. Competition amoung clients is a good thing.

2024-08-30 21:18:54

- reply

It relays all the things (well, in a specific format)
It doesnt, for example, store all the things. For that you need other technologies.
Nostr is a tool in the toolbox.

2024-08-30 19:44:23

- reply

Plain Old JavaScript is highly under rated

2024-08-30 16:34:02

You cant create free markets on a rigged base layer.

2024-08-30 16:14:55

- reply

Largely agree. I think colored coins are going to grow in utility and popularity, because they create free markets on bitcoin base layer. We see in the real world that free markets are major use case. It's something that could be as big as bitcoin itself, just if you look at the dematerialization of what exists in the financial world. So an expanded middle section of the mempool would facilitate this, increase security budget, decrease fees for L2 and onboarding, and keep the network sufficiently decentralized. I agree alot will change in the next, say 4 years, simply because AI will mature and affect so many things. AI will also incrase demand for block space. Important to remember that one of the main reasons for decentralized node network is to ensure that the coins were emitted as a level playing field. After that is 99% accomplished, so much more is possible.

2024-08-30 16:02:56

- reply

Very valuable, thanks!

2024-08-30 16:00:17

- reply

You have the patience of a saint. The 7 TPS is a red herring. Bitcoin scales through layers. Each layer is a trade-off. If it was not a trade-off it would be the base layer. The layered system is still vastly superior to the status quo. I do however think that after 99% of the coins have been fairly emitted, there is a case to increase capacity TPS in line with the hardware of the day, and balancing it with keeping the node network decentralized.

2024-08-30 14:05:41

- reply

Could be! But the web is already designed to integrate reading and writing nostr events via http GET and PUT. You can also point to a relay using an HTTP header.

2024-08-30 13:44:35

Few people know that the original web was designed a decentralized space where everyone could browse and edit thei own pages. The original browser, called worldwideweb, was a browser/editor, where anyone could make edits to the web as well as browse the web. What happened next was that VCs removed the editing functionality and created web based silos which locked in the users. We now have a chance to add back the decentralized functionality to the web, returning it to its decentralized roots.

2024-08-30 13:14:26

Ditto scales, so nostr doesnt need to. And through federation ditto has already scaled to millions of users and growing. You dont have to use ditto, just take the design patterns. Not only that, but we can add almost unlimited features to it.

2024-08-29 15:07:37

Great to mean Alex Gleason and MK! Bullish on ditto.

2024-08-29 10:39:42

- reply

It feels like it, but it isnt. Nostr is controlled by one entity. If it transitioned to community based, like bitcoin, it would be good. Might be a bit late now.

2024-08-29 10:34:28

- reply

yes

2024-08-29 10:12:22

- reply

I'm starting to think that gold was a premine (in africa)

2024-08-29 09:59:02

- reply

Not quite right. The bottom half is bigger in the Jungian model.

2024-08-29 09:11:08

- reply

Main thing with bcash is that there are hostile forks (such as bcash) and complementary forks (such as litecoin). Bcash was the most hostile of hostile forks, it took code that it didnt write, and tried to destroy upstream bitcoin, so that they could take all the coins, which gave that code to the world for free. It's like stealing your neighbours car and trying to run him over and kill him, so that you can f*ck his wife. When your plan fails, you say, hey cant we just be friends. No, you cant.

2024-08-29 08:37:42

- reply

It's the future

2024-08-29 08:35:38

- reply

Yes

2024-08-29 07:46:31

- reply

https://m.primal.net/KTHw.png

2024-08-29 07:20:08

@npub16c0…6nvr could we fix this bug, seen at least 5 times. People coming to primal cant follow someone if they are on 0 followers. That's a v bad UX.
https://www.reddit.com/r/nostr/comments/1f3t262/cant_follow_anyone/

2024-08-29 07:13:07

- reply

Allows interactive posts and buttons etc.
https://m.primal.net/KTFo.png
https://m.primal.net/KTFq.png
https://github.com/nostr-protocol/nips/blob/ddd26ebbade91cecbe867b6bac0407cb2367ef0b/22.md

2024-08-29 07:06:28

Upvote!
"This NIP introduces the concept of Smart Widgets for Nostr clients. Smart Widgets are customizable, interactive components that can be embedded within Nostr events. These widgets allow users and developers to create rich, dynamic content that enhances the user experience. This proposal outlines the structure, implementation, and potential use cases of Smart Widgets within the Nostr protocol."
https://github.com/nostr-protocol/nips/pull/1454

2024-08-29 07:05:21

Cant right now, babe, smart widgets spec just dropped ... that's right SMART WIDGETS for nostr!
https://github.com/nostr-protocol/nips/pull/1454

2024-08-29 06:58:31

Meanwhile, in nostr dev chat, censorship resistance is going swimmingly ...
https://m.primal.net/KTEl.png

2024-08-29 02:51:57

As the one who came up with the inbox model behind Solid and ActivityPub, I can't help but find the outbox debate pretty amusing

2024-08-29 01:26:23

- reply

Nostr's really just a subset of HTTP—how you use it matters. The freedom angle feels a bit overhyped. People might think it protects them, but it could end up storing signed evidence forever, potentially more risky than regular socials. And let's not forget, some devs slip spyware into big sites. Personally, I see it more as a tool for social app portability, letting you move between sites easily. That's the real value.

2024-08-28 21:26:03

"reducing load on public NOSTR relays" -- please dont use public relays for this
#note1skq…gf0l

2024-08-28 21:23:38

- reply

Why base32 encode the pubkey? Why not use the hex which is the canonical form?

2024-08-28 21:00:49

https://m.primal.net/KSPW.png

2024-08-28 20:28:51

- reply

Nah

2024-08-28 20:28:07

- reply

cool! yes im having the same trouble with dvms. this pattern with a node server sounds very good, exactly what i mean by using nostr as an API

2024-08-28 20:26:32

- reply

If it's just an API, then what you use it for, freedom or otherwise, is up to you.

2024-08-28 20:11:55

- reply

You mean existing end product using relays? Or something to connect a relay to an existing product, like a bridge? That could be huge yes.

2024-08-28 19:45:01

- reply

I think nostr could help do the handshake, then you figure out where the audio files are. Then stream it client server, or through an audio relay. So if nostr is just an API you can figure out what tool to use, it might be nostr, it might not be. As a developer you have freedom to choose.

2024-08-28 19:39:10

- reply

I didnt strictly define it. But something like a tool in your toolbox, rather than the toolbox itself.

2024-08-28 19:37:59

- reply

The analogy is that you have a working system and add an API, ie add nostr. Rather than using nostr as a starting point. So, say, activitypub could use nostr for realtime updates. Git could use it for single sign on. Twitter could use it for micro payments. And so on.

2024-08-28 19:36:24

- reply

You are correct, I defined it loosely, or didnt define it. But it's more of an analogy. API being a tool that you use, one of many. Rather than the main system on which you build. If that makes any sense!

2024-08-28 19:33:16

Nostr is better as an API than as a protocol. It might end up as either. If it's an API it doesnt need to scale, because it inherits scale from http. So you use the API and are happy. I think that's where it will end up, but it could go either way. Both are good outcomes.

2024-08-28 16:29:38

- reply

The best website that nobody has heard of:
https://learnmeabitcoin.com/technical/keys/hd-wallets/extended-keys/

2024-08-28 16:22:15

- reply

I'm still reading through it. I'd prefer open ended subkeys, but maybe I can live with this. Need to figure out the details. Could be like an xpub, but I thought that xpub is longer than an npub. Need to refresh my memory, there.

2024-08-28 15:03:01

"IETF MLS, Message Layer Security, scales Signal-style encryption to large group chat using Merkle Trees. Is in process of being implemented on Nostr too!" -- Harry Halpin
https://x.com/harryhalpin/status/1827976195746783674

2024-08-28 14:24:34

- reply

There are indeed multiple paths forward to scalability. But nostr hasnt really explored this yet. There's a lot of hope that the gossip model will solve things, but no evidence that it will.

2024-08-28 14:04:06

- reply

Nostr isnt designed to scale at all. Connection oriented networks dont scale very well. But they can do a decent enough job.
Sufficiently decentralized is orthogonal to scaling and imho a red herring. We know what scales through observation and we know what doesnt scale through observation.
Nostr was under 100 users 2 years ago. It's done very well to get where it has, but it wont overtake the internet, and isnt designed to. It's a very useful tool, and unlocks a lot of developer innovation and creativity. Working as expected.

2024-08-28 13:56:25

- reply

Connection-oriented networks carry overhead because they need to maintain continuous connections, which doesn’t scale well as the network grows. The web scales by focusing on stateless interactions and efficient caching strategies.
For Nostr’s caching, consider distributed caches or edge approaches to reduce server load.

2024-08-28 13:50:46

- reply

should get this dude on nostr