Tienen que adivinar cuánto cuesta en sats ⚡

Es en Argentina 🇦🇷

#meme #memes #memestr #nostrmemes #hispano #hola

Those have purpose so I think they're fine. It's the engaging like a human ones that are worrisome.

If there will be more AI/bots on nostr that you can no longer tell the difference, this place no longer holds any value to me.

Tape echo affectionados, Prog Rock appreciators and Tottenham Hotspur fans. Ok Tottenham fans might be a bit too niche, even for this place.

Oh and the actual Ossie Ardilles.

Consideran que hay menos hate aquí en nostr que en otras redes sociales?

PAYMENT TIME PERIOD?

Si se hace un acceso restringido al PoS (receive only) no pasa nada, puedes usar cualquier cuenta.

Puedes configurar en una tablet (para el empleado) un AlbyGo solamente con cuentas NWC receive only. No se falta poner cuentas full access.

Vertically integrated specifications win.

Instead of thinking of NIPs as “horizontally integrated” lego pieces where given kinds are specified based on their functionality with the goal of being usable in as many types of clients as possible, we should create NIPs that model a given type of application with all the requirements of that application listed in the NIP itself.

Take our Blog kind for instance. It’s essentially an extended version of a Kind 1 (twitter) post but with support for Markdown. In theory, we could have just re-used kind 1s. But we didn’t. We created a whole new spec just for it. Now picture a new client specifically designed to write and display Scientific papers. It’s essentially a “Blog” king, but its Markdown support requires the addition of Latex Equations. Should we modify the Blog post kind and force all Blogging platforms to deal with and maintain the code complexity of rendering latex equations? Or should we just add a new NIP just for scientific publications? If we want to keep Nostr simple, new NIP it is.

Now picture a dev that wants to offer a Blog platform for scientists. It’s not a Scientific Paper platform, but it is also not a regular Blog post client. Should we create a new NIP with a new kind? I say yes. Because with separate NIPs each blogging client and each scientific paper client can decide to support the other kind variations in their own timeline, if their brand and user experience allows them to support it at all.

That breaks the way we Nostr:

1. User expectations that all blogs/papers are the same stuff and must be seen in every client is wrong. Some users even say that by not supporting certain kinds, devs are failing interoperability and thus "destroying Nostr". Some users want to see the exact same "feed" in all clients. This is not a good expectation to have. Blog post apps should not be expected to render scientific papers and vice versa, even though they are functionally very close to each other.

2. The NIP repo’s rule that there should be “no more than one way of doing the same thing”, which is a good rule that seeks to increate interoperability, is wrong. Sometimes applications need a different way of doing the same thing. Like the scientific paper need, it’s fundamental to their own existence but it is just another way of doing the same thing from a technical perspective.

While I understand that most devs like specs designed for “horizontal integration” because they simplify their work (write once, run everywhere), it’s become more and more evident that Nostr’s simplicity can only be sustained with vertically-integrated specifications, and devs that support multiple similar kinds at the same time need to duplicate their work to support the required variations of each NIP.

This will generate many more kind numbers than initially expected. And that's is just fine.

LN is terrible for moving large volume. The larger the transaction the higher likelihood it will fail. And if you think Monero hourly transactions are small wait until you see Liquid. So no, nice try, L2 is not any significant part of those transactions lmao. It's mostly CEXes/custodians.

Also, check the market caps and userbase of both. Monero is a tiny 0.2% the size of Bitcoin but regulary hovers around 5%-10% tx count of Bitcoin. Punching way above it's weight.

>"The CEX’s reduce on chain usage"

ATHs + no/low on-chain usage means vast majority of activity is taking place on custodians/CEXes. This just means a majority are transacting with custodians which isn't the flex you think it is.

>"two weeks in a row where time per block decreased to 9 min. Now is back to +10 min and is full again. "

I'm talking about transaction count.