Bluetooth itself was the perfect spam filter for Bitchat. And with a bit of creativity on the use cases then Bitchat could have totally scaled on Bluetooth alone.
I've no idea why there was a sudden need to "break out" of the Bluetooth comfort zone. Now we have all this spam naval-gazing.
Yeah that too! But lightning so I can use it with Cashu, ulterior motives.
Potentially I suppose. For me though, bluetooth is the magic. It solves the spam problem and it also makes it a unique thing. And lots of room to scale bluetooth use cases, if you get creative.
Now I don't really know what it is.
Stablecoins on lightning. Win-win.
Maybe in parts of Europe or where have you. But out here in Asia, it's not like that at all. If you look at how the superapps like Line and Kakao are integrating stablecoins, it becomes part of the superapp ecosystem, no "crypto thing" vibes, just US dollars or Japanese Yen that are somehow "digital".
https://www.ccn.com/news/crypto/tether-line-usdt-payments-messaging/
One is several orders of magnitude more realistic than the other. Whether that's enough to be realistic overall is an open question, but you can't ignore the discrepancy there.
Course not, but it's in the ream of "realistic ask" now. Whereas Bitcoin Sats, no way.
Are you kidding? The volume of small retail transactions in USDT makes the volume in Bitcoin Sats look teeny tiny. Like a fraction of a percent. And getting a hold of USDT (or regional stablecoins) is far FAR easier.
Stablecoins are coming to the lightning network, that's the way in. By this time next year the amount of stablecoin volume on the lightning network (mainly USDT) will be pretty crazy, wait and see.
Yes, 100%, absolutely!
Gotta hammer this home.
Proof of work is a fools errand, especially on mobile.
Pre-minted cashu tokens that can be validated client-side, that's the way to go, like quarters that you drop into an arcade game.
I think you've hit on the general idea.
Thing is Bluetooth is (reasonably) spam-free because spammers would have to be physically near you to spam the chat. By extending it this way you introduce spam, and then it becomes a game of cat and mouse, which pretty much always ends up in either abandonment (like NIP28) or centralisation.
The whole thing about Bitchat was Bluetooth...
>We are working on a POC of the later 🛠️
Bleeding-edge stuff, great news.
Ah right. Though “pay back" and "cash out" would be seen as the same thing I feel.
The only path to argue that I can see is to argue that Cashu tokens represent a form of gift certificate. But gift certificates are supposed to be non-monetary, limited-purpose instruments. Depending on the country, customers can sometimes get a refund on higher-value gift certificates, often on condition that they ID themselves and jump through a lot of other mandated hoops. But for smaller gift certificates the merchant is not allowed to refund. And when it comes to giving change, usually the customer can't get back any change except if it's a small amount in view of the original value of the gift certificate. So they’ll just add a pair of socks or whatever to use up the remaining amount.
What you’re suggesting might work if you *must* spend *all* your tokens at that merchant (once obtained there is no way back to the lightning network for your tokens drawn on their mint). But then besides some of the niftier programmatic aspects of Cashu you lose a lot of the value and it becomes something like a virtual in-game currency. Cashu could still be a good backend for only that though, which goes to show just how versatile it is.
Employee-facing use cases for businesses, such as small-expense reimbursement (think of a Cashu-powered Expensify) and other things like internal employee rewards programs. We're actually going through a VC accelerator out here right now to try and get funded for a Cashu + these types of use cases pitch, so fingers crossed. (We're in the "VCs can be good people too" camp.)
These use cases are generally much easier via a vis regulation, as the employer-to-employee payment relationship is a whole different thing from the regulator's point of view.
We’ve talked to a few regulators in Asia about that very model specifically.
The crux is that it’s not generally seen as a closed system.
A BTC Pay server doesn't hold funds or issue tokens. It just automates the process of generating invoices and verifying that a payment has been made to the merchant's wallet (or whatever).
A Cashu mint though is a tokenised credit system, which most regulators see differently.
For example if you're a merchant and you issue gift certificates then as long as they can't be exchanged for cash (either outright or by giving change in any serious amount relative to the gift certificate's value) then you're good to go in most places. But for Cashu the holder can cash out anytime, either remaining value after a purchase, in any amount, or they can cash out the top up without purchasing, etc. So it's open and exchangeable.
In some countries that's a grey area, but in others it's pretty clear that this is a regulated use case.
If looking for Cashu entry points that are less likely to require regulatory green-lighting then I think there are better ones than this, again though depending on the country.
This use case would require regulatory cover in most places.
This will be possible when USDT lands on lightning in usable form. Should start appearing in a month or two, but someone needs to build the rails from taproot to cashu.
It's neat in theory but for us this needs to be deployed on business customers' own infra, and we can do that with a mint, whereas for liquid you'll always have that outside factor.
Reddit is doing well overall.
https://blossom.primal.net/2d78752abff74da615890e46006356cd98408c889534135be5848159c28f7530.webp
I'm pretty convinced organic diversity is cultivated by having organic diversity from close to the start of the protocol. Not by a killer app, or by centralised servers, but by raw timing.
Which means the best option might be a full restart.
I think most do see bitcoiners, and think this is a bitcoin group, and that's it. No more complicated then that. Just someone told them try nostr out (you can own your account, etc.), they came, found out it's all bitcoiners, they don't care much about bitcion, so they left. That simple.
If someone told me to try out a social network that "lets you own your account", and I jumped in to check it out, and all I saw it was all Warhammer 40,000 people posting Warhammer 40,000 things, I'd be like 'well I guess this is a Warhammer 40,000 club', and I'd jump out.
I don't think big picture stuff like how this compares to the centralised experience even has time to enter the picture. People are out before they've even kicked a single tire.
On that note, Farcaster and Nostr both seem to be victims of community capture.
Bluesky is at risk of corporate capture, but not so much community capture, as there's no one community you can point to as owning the place.
ActivityPub seems to have avoided both, so good for ActivityPub.
Good to know, I'll try jumble. Also the igloo route. Those igloo guys are doing hard work. I personally think TEEs are the way to go, working on that side of things now, but let's see how igloo goes.
"Bitchat" is trademarked in the EU in Class 9 (mobile apps, etc.). If the holder filed a complaint or if it was discovered later on then these things happen, a very common thing.
Im trying to think where that would actually be useful. Like who would be motivated to support such a matrixed-up setup and why?
This is kinda like RGB, where as you say *someone, somewhere*could use that. For something. But it's hard to think of who and for what.
Now Axiom's argument has moved from "it's not technically possible" to "there are so many social pressures that nobody would dare do that".
Quite a shift.
I wonder how many of the nsecs of us early Nostr people are sitting in some sleeper database right now. Probably a few!
Also tried the communities.nos relay, same issue w same phones, so must be client side I'm guessing.
Even for a signer app you are putting trust in the owner of that signer app.
Though you can take the code and publish it to your own app store account if you have one.
And there are some albeit super complex ways to attempt reproducible builds on iOS.
https://core.telegram.org/reproducible-builds
Remote signing can solve some of this, we're working on that via the cloud route but it still requires some trust in AWS or Intel. (Though I'd argue it's close enough to being trustless.)
F-Droid's servers download the source from Github or Gitlab and compile it on their own server. APK is signed with a unique F-Droid key for that app. Third party can then reproduce the build, the two APKs should be byte-for-byte identical. They have a system where they show the results of these independent rebuilds, or a user can just rebuild it themselves. Gets a bit tricky if the app includes non-deterministic elements that make it hard to rebuild the same each time.
None of that applies if you don't want it to though.
That said I’m not sure if there'd be enough demand for someone to code up a pubky client that serves users who want the atomic model. Could be I suppose. One way to differentiate.
*quit