Yep. Peer validation is a driver for more zaps too. It’s also a network effect if shared or reposted as well, brings new eyes and such.

Some great ideas and thoughts 🙂

I liked the average zap idea as a concept - it helps set a kind of market price people can compare or evaluate against their own perception.

I think project based funding with rewards is a different scenario than I was focused on. I don’t see it as value for value.. more support this cause or fundraiser.

I’m more looking at ZAPed Nostr posts, blog posts, etc. More reaction and higher volume (usually smaller amounts), than the explicit ‘Fund this project target’ style.

It’s tough. It’s a transitional period where alternatives are often not available or not as usable.

Effectively yes. Investing in themselves as opposed to other opportunities.

It’s often a market buy signal, however the market prices it in pretty quickly. It also means less shares for sale short term, and can drive prices up - however often the shares they buy back are not via public exchanges and instead private off-market deals.

Is there any good comparison between the two? I likes both, but haven’t compared recently.

Yep. They are effectively backing themselves for growth better than the market price forecast or other investments.

Zap amounts can be fake too. It’s an unwarranted and trusting model that it is deceiving. Zaps cannot be trusted.

Googles new secret sharing scheme. It’s called plain text. Highly innovative and approved by Five Eyes.

We need to get off this trash so badly..

nostr:note1pqd4r7vtxddy2rf8yvztrmwla6eu3sjpcwtddgd7qd465mdgumlqzflh9l

I hadn’t checked. You’re right. It’s literally down to around 1,000 events an hour for me.

Maybe due to china firewall blocking, as a significant amount was Chinese language focused - and it’s all but disappeared.

Most of the spam was from a few set of actors. It’s scary how few people can create so much noise. We still need to be prepared for larger attacks going forward.

One risk with value for value public payment models is that people may see N amount of zapped sats, and think, “that’s received enough compensation”. Their internal model of what something is/was worth is in equilibrium - yet the global utility/value is still higher.

It may translate into a deferred or more balanced zapping across content - however it’s likely to be a friction point too - where people internally question the above before contributing, and either zap other things or fewer things.

That’s how discord and telegram bots do it today. Autocomplete is hard because mobiles don’t have a tab button on the keyboard.

I have a few bots and they fallback to a cli like help text for unsupported commands or input errors.

I don’t know if a special command selection UI could work (adoption would be hard), however if you brought a way to dynamically generate forms that can be supported it may be cool.

Examples

CommandA - which can have an autocomplete pop up searching their name. Maybe even support adding multiple pubkeys via auto-select like the tag input fields.

Or

CommandB - which can show a new metric pad.

Cool to see the defects.

Zap validation is also expensive (network requests and computation) and multi-step and also stateful.

If I change my lud, all previous ZAPs now technically should fail validation, unless you change it back. You either need a profile/lud snapshot at the zap time, or to validate zaps instantly (read: race condition and impossible in a decentralised network) and record that outside of Nostr, to the query later.

Zaps are awesome. But they aren’t trustworthy or polished in many ways. Hopefully we can iterate.

One day the central banks won’t be so central.

#3 can be reworded to ‘focus on fewer nips, seeking better outcomes, with greater collaboration’.

Often NIPs are read or worked on by five or so people, yet impact dozens of devs. Very commonly they don’t extract out the general use case, but target a single dev’s target problem today.

A good example is the server AUTH spec. It was never intended for general webapp or api login. Targeted websocket messages by adding a new command (Nostr literally only has four.. so adding a fifth is significant).

That NIP was so focused on a way for DMs to only be queryable by sender/receiver + pubkeys, that it excludes web app login, API auth, and all use cases where you may want or need to prove you hold the private key - like subscriptions or private relays.

If more a collaborative process was happening, it could have been generalised, people have realised websockets use HTTP to connect and supports headers, and we can create a common event kind that works for many use case, and apps can implement once and one NIP.

Devs get very excitable and tinker (including me). That’s important and valuable.. but we need some layer of collaboration on top of that.

I just hope the Nostr CEO approves renaming to ‘we’.

Great. Thanks.

I don’t want to make Nostr a septic tank of data mining. But I’d like to at least be aware and open in discussion around what data is available - so people can understand better.

“Esteemed ladies and gentlemen, now is the time to take our assigned seats. It’s not the time to pack bags or search for a better seat. This is a fully booked flight.” 🤣

*migration..

#DestroyAllKeyboards