Joe
Joe working on B2B

Anyone else working on B2B solutions using nostr architecture give me a shout, happy to sync.

Public Key

npub1hyxredcavc6ruqgsf4wf4hmakpwnvefmzaspl7dja6a2sxlx0q3sxwtqnx

NIP-05 Address

joe@milliwatt.com

NIP-57 Address

zaps@primal.net

Profile Code

nprofile1qqstjrpukuwkvdp7qygy6hy6ma7mqhfkv5a3wcqllxewaw4gr0n8sgcpp4mhxue69uhkummn9ekx7mqpzemhxue69uhhyetvv9ujuurjd9kkzmpwdejhgsrh92p

Publishing to

nos.lol

relay.primal.net

relay.nostr.band

Author Public Key

npub1hyxredcavc6ruqgsf4wf4hmakpwnvefmzaspl7dja6a2sxlx0q3sxwtqnx

Show more details

Last Notes

2025-04-25 07:41:00

- reply

App Store review was always going to be a dandy. Have you got a Primal-seque in-app purchase flow scoped in case they force it to keep zaps on posts?

2025-04-25 07:38:03

- reply

Just tried, works great, nice job guys!

2025-04-23 14:54:46

- reply

That's essentially just a client and a signer in one no?

2025-04-20 20:36:40

- reply

My take is it's pretty much the same as what would happen to Nostr there, if Nostr weren't so small.
Right now these "banned" bluesky accounts can be accessed in Turkey by at least 3 or 4 other bluesky clients (atproto clients), including iOS, Android and web. And probably several more. But that's because the Turkish government sees these other clients as inconsequential.
The key point is governments these days are far more tech-savvy than they used to be.
Nostr would be no more resistant to the censoring efforts of a tech-savvy government than atproto, or farcaster, or pubky, or keet, or anything else provided it were big enough. All would be trivially easy for that government to make useless for the majority of its population. In a week.
When talking of censorship resistance it's only really meaningful if talking about resistance to in-house censorship. To in-house moderation teams. Anything on the government side—that's a fever dream in 2025. If you're big enough or sensitive enough to be deemed necessary to censor then you're censored.

2025-04-20 20:05:44

- reply

What are these protocol-subverting/poison-pill moderation tools?

2025-04-18 11:46:20

- reply

to be clear, it's limited by how much can be accessed by digging as gold mining companies are actually able to dig, excluding some giant and unforeseen leap in mining technology.
course the calculation for bitcoin could also be upset by quantum and other technologies, so there's always that x factor.

2025-04-18 11:05:23

- reply

well no, obviously not. it's limited by how much there is.

2025-04-18 06:40:29

- reply

Maybe, but let's be honest, people here are pretty cheap.
You look at some of the better longform stuff (that is before longform all broke) and it's stuff that would have a great amount of time to research and write, isn't available anywhere else (totally exclusive), addresses primary concerns of the nostr community—and still it gets zapped here barely enough to buy a small bag of sunflower seeds.
At this point, pretty sure there's no type of written content that one could post to nostr regularly and be reimbursed at minimum wage for the time it took to write it. At least consistently over months.
Best way to earn sats from posts is to be famous elsewhere first and say hello. But that wears off after 5 posts.

2025-04-17 17:08:02

- reply

You as well. For what it’s worth the social over ham stuff you’re doing is very obviously valuable in my mind with or without bitcoin.

2025-04-17 15:37:09

- reply

To me it sounds like assumptions, built on assumptions, built on assimptoins.
I watched this podcast this afternoon, and it seems to me to be a far more down-to-earth assessment of what Bitcoin is and what we can say about it without venturing into fortune teller territory.
https://www.youtube.com/watch?v=Cin3__czDco

2025-04-17 09:41:38

- reply

> it dissolves the eons old human control structure, and keeps it from ever taking hold again.
This argument has always been hard to parse. It's like if there was no such thing as solar power, all electricity was from thermal plants controlled locally, then one say an inventor said "I give you solar power, you don't need permission, it works everywhere on earth, we will now dissolve eons old human control structure..."

2025-04-17 05:45:12

- reply

Not sure what the analogy is, the dollars in your savings account don't change their fundamental properties when you place them in there, they get spent by the bank here there and everywhere, and the returns accrue as interest. If Bitcoin becomes a transactional currency it'll appreciate or depreciate within the bounds of everyday life, as all transactional currencies must.

2025-04-16 20:02:45

- reply

Yes, this very much confuses me. Many opinions here seem to exist in a quantum superposition of "stack sats" and "spend sats". It seems so obviously logically inconsistent.
The folks that are all in on store of value—the "I'll never zap a single sat" crowd—are at least understandable. While I disagree that Bitcoin will ever come close to gold, at least I get the position they're staking out.
But those that are "store of value" one day and then "day-to-day currency" the next day, I really have no idea what the thinking is.

2025-04-16 18:49:28

- reply

I like that your team is building something for nostr that makes sense as per the original nostr blueprints.

2025-04-16 14:50:16

- reply

One thing I wonder is that nostr ethos seems to be all about spending bitcoin, making it an everyday currency, buy your coffee, buy your bacon and eggs. I’m not an economist by any stretch , but it stands to reason that there would be a push and pull between everyday currency and store of value. When it comes to gold, people don’t trade their earrings for their breakfast.

2025-04-16 14:09:52

- reply

That seems to assume a fixed external measure, in this case $. Not that I have any idea how three body problems work in math.

2025-04-16 13:38:41

- reply

For discussing certain theories I suppose that's a useful distinction. But for me the assertion that gold will go to 0.000[infinite more zeros]1 seems just as unserious as the assertion that gold will go to 0. Even to assert that the value of gold will approach the value of, say, copper—I can't see how that could happen in the next 100 years.

2025-04-16 13:15:58

- reply

Hmm, in that case "trends to zero" sounds like just a euphemism for "goes down".

2025-04-16 12:41:21

- reply

What Orwellian wordplay is this?

2025-04-16 11:48:06

- reply

How does gold trend to zero? We've already minded like 70-80% of the earth's gold, with pretty high confidence.
Of course asteroid mining could change things, or maybe some large deposit could be found somewhere totally unexpected vis a vis the modelling—though even that wouldn't likely change things by more than a few percent.
So the scarcity part seems pretty legit. And I don't see our race falling out of love with traditional concepts of jewellery anytime soon, to say nothing of gold as an accepted abstract store of value.

2025-04-15 18:39:46

- reply

> in order to be sovereign you have to run your own home server.
How could one be sovereign otherwise? If all one's notes are stored on relays that someone else runs, is one sovereign? if all one's photos and videos are stored in someone else's AWS account, is one sovereign?

2025-04-15 18:07:32

- reply

It's working. I use Amethyst follower counts as the backend for the random number generator that powers my online roulette game.

2025-04-15 16:34:11

- reply

I dunno what to tell you, that's just flat-out factually wrong. Read all the articles in this blog, you'll soon figure out why what you said results from a fundamental misunderstanding of how things *actually* work.
https://medium.com/pubky

2025-04-14 18:49:13

- reply

>A global state that most actually desire, because everyone seeing a different counts, replies, top trends, etc... is frustrating UX.
This 100% agree. If you make the uncertainty part of the pitch then that's cool, who knows, maybe chaos sells. If you try to hide the uncertainty with pretend absolutes then the UX doesn't just become frustrating, it becomes comedic.

2025-04-14 18:23:07

- reply

Question is should Primal, Damus, etc. show follower counts?

2025-04-14 16:32:14

- reply

Look at the example at the start of the chain though. There's a pretty big difference between 800 followers and 20,000 followers. It makes the whole network look silly. And it can't be more exact without full-network crawling and indexing.
If you see a job advertisement with a salary listed as "From $100 to 10,000 per month" will you take that company seriously?

2025-04-14 11:44:57

- reply

I’d add that I don’t even trust myself not to leave cash in my pockets of my jeans that go in the washing machine.

2025-04-12 21:21:55

- reply

yes that's what I mean

2025-04-12 20:23:36

- reply

I would actually rather that Damus not keep trying failed relays after those few initial seconds, and then when it gives me the X of X report I know that's the end state of things unless I take some action myself. If Damus is going to keep trying then all that "result" is is just a status at a point in time, and that status could be different one second later.

2025-04-12 12:19:18

- reply

Times have changed. Most people selling on Instagram or TikTok today, for them it would be unthinkable to focuss on their own website and build an email-list as an actual alternative (i.e. with a view to giving up on Instagram or TikTok).
And yes of course it's chicken and egg. But in this case I think audience/customer base must come first, before you can even start to talk meaningfully about censorship resistance. Most chicken and egg problems are solved by coming to the understanding that either the chicken or the egg is in fact more fundamental.

2025-04-11 11:05:19

- reply

Expat communities are a good one. "Expats in Bangkok". "Expats in Lagos". That kind of thing.
Bitcoin is useful because you're already dealing with a mad mix of currencies and cross-border fuss.
Anonymity is useful because grumpy expats tend to shoot their mouths off, even in countries where that's not to be advised.
You'll also catch a lot of digital nomads with that net, and they'd be more likely to get into the whole dev side of the Nostr conversation.

2025-04-11 08:56:41

- reply

MLS would appear to be a pretty fundamental building block there. MLS can be a bridge between Nostr, atproto, Farcaster and others, and MLS can really scale. Example of one of the many ongoing atproto MLS discussions:
https://github.com/blacksky-algorithms/rsky/discussions/70

2025-04-08 16:44:20

- reply

Depends which. Some brands and companies, sure. The low-hanging fruit. Small teams, tech savvy, like Alby. The 1%, basically. There's enough in that 1% group to get going.
But the CPG, FMCG and retail brands I've worked with most of my life, little chance most such brand teams could (a) handle a setup whereby the secret was both forever unknowable to all and forever under control of the brand or (b) accept a setup whereby the secret is (or can be) known by even a single employee that could go rogue—which is all employees in the eyes of most compliance departments.
Basically brands needs brand safety, it's a #1 concern, and compliance departments (which have to clear these things) will never allow such a risk to brand safety to be present.
Even getting to the point where you can have a meaningful conversation about keypairs and bunkers with decision makers.... This here Nostr world is a world removed from their world.

2025-04-08 14:48:11

- reply

I think it's fine for types of communities where the community creator ceding control of the community to another person would make no sense, because that community is so tied to the creator's personal brand. If the creator can't go on managing it then the only option really is to shut it down.

2025-04-08 14:10:32

- reply

I dunno how you plan to structure it, but we found the issue can be both.
The mint needs the URL, the server, the associated LN node, and whatever basis for AUTH (database or other). A community member could spin all that up independently, and manage access independently, so not asking Zapchat to assist with any of it, nor letting Zapchat know the URL or any other details of the mint in a formal-input sense, or of the mint transactions—it's all discussed in MLS e2e encrypted messages and all transactions done outside the client.
That would be no different that a bunch of people spontaneously agreeing to do all that with each other in a Signal group chat. Then Signal itself can legit say "we can't know anything about that".
But for the mint to actually be a basis for fun features then a bunch of data on the mint, the users and the transactions will have to pass through Zapchat's servers, of those of whatever other client, no getting around.

2025-04-08 11:57:06

- reply

That was our first approach—you know everyone in the wider transaction pool but can't associate any individual transaction with any individual person. Doing that, however, ties the mint, the community, and the client all together in a certain critical regulatory sense. So if we had a Nostr client that was an EU entity then that entity would be a potential enabler of all activity on all mints in all communities (public and private) created in or accessed via that client. Same for many other places. That's the tricky part.

2025-04-08 11:30:23

- reply

Our use case is private too, but in many places the regulator could care less about any private/public distinction. We looked at locking down a mint to a private group via various means, but lock it down too much and you've made the blind signature aspect irrelevant, lock it down too little and then all the AML stuff. (Actually all the AML stuff often regardless.)

2025-04-08 10:36:32

- reply

The mint part is not so simple. Small scale, no worries. Moderate scale, many worries.
First of all it may be illegal to run an unlicensed Cashu mint operating at even moderate scale in many countries. At small scale (groups of a few friends or family members) probably fine, grey area and all. But the mint starts doing any volume in these countries and then no.
This is because of what a mint is to these countries—basically a digital bank, with deposits like a bank, withdrawals like a bank, potential to fail like a bank. In regulatory terms this is very different to running a personal LN node, even with the same volume, or smaller.
In the EU a Cashu mint might come under MiCA, and some larger community mints might become de-facto VASPs under MiCA. (The VASP categorisation doesn't actually take volume into account, rather the nature of the service, what the mint is doing, how businesslike the whole operation is, etc.) If I was an EU citizen then I'd never allow myself to become the head of a Nostr community with a busy mint that ran on my server, regardless of what the community was about.
Regardless, all it may take is one or two larger community mints rugging the community for these regulations to suddenly become more in play. Also community mints would be very vulnerable to smurfing, which is a type of money laundering vector where agents will make many small transactions through a mint; if a community suspects its mint has become a smurfing vector, what is it even to do to? It gets messy fast.
Obtaining the license could be faster and cheaper in a jurisdiction like Estonia, Malta, etc. but that will require an entity in that jurisdiction. It'll also mean AML and CTF obligations, which are tricky in a Cashu context.
This is not a popular topic here, but it is what it is.
Throw in selling Sats for euros or dollars (a whole other type of license) and the community owner is going to be putting themselves at a higher degree of risk in these countries. Not to mention how to collect payment? PayPal won't allow it, Wise won't allow it, Venmo won't allow it (underneath Visa and Mastercard won't allow it), so how is the person buying the Sats to pay the seller in a way that is compliant? (Apps like Peach try to tiptoe around this but Peach won't scale, and anyway average commission on peer to peer Sat purchases there is like 20%, due to sellers wanting to be compensated for the risk.) So basically the community would always be under the table—if not in one context then in another.
Again all of this depends on the country—the country of the mint itself, and of the users of the mint.
Anyway zooming out these are scale concerns for which Nostr is pretty far right now, and also stress testing the idea (for our own use case). TLDR small-scale casual community mints I think are a good idea, but only for close-knit groups of people who already have their Sats in hand.

2025-04-08 08:25:22

- reply

Have you given any thought to have a minimum zap threshold might work? I guess it'd have to be client side. Or maybe a "nutzaps fixes this" scenario, like everything else (choose a mint that enforces a minimum amount).

2025-04-08 08:08:09

- reply

It's the easiest option out there, but if topped up with in-app purchase (which 99% of newcomers will do) keep in mind Apple takes 30% of the payment, which is a much bigger concern than the light KYC. Also in-app purchase of Sats will only work in 30 or so countries.

2025-04-08 07:35:54

- reply

It's very difficult to acquire Sats, that's the main issue for me. Person X may have become aware of something fun to do on Nostr, and they've discovered they need these things called Sats, which are apparently Bitcoin pennies of a sort—but how to get them? That's where it breaks down. All the options out there present an order of magnitude too much friction.

2025-04-07 22:40:57

- reply

Bitcoin integration is a uniquely special feature of Nostr—for people that have Bitcoin to spend. Which is a tiny, tiny fraction of internet users.

2025-04-05 12:42:42

- reply

Is this giving the Disrespector new material?

2025-04-05 08:18:54

- reply

Cool, looks good, much better logic.

2025-04-05 07:53:40

- reply

Looking forward to new design

2025-04-04 16:32:00

- reply

Inline styles on steroids, what could go wrong?

2025-04-04 11:35:09

- reply

You could have each person decide if they want the bot to @ mention them in a kind 1 or just DM or both.

2025-04-04 11:27:47

- reply

All via kind1 posts, no DMs

2025-04-04 11:26:12

- reply

When the person joins the community, the bot will spin up an account and greet them, hey welcome to the community!. When an event is rejected, the bot will explain to them what happened, (again this is just a mention, but the person can also follow the bot account for regular updates). The bot isn’t posting anything not directed at that specific individual. And when the person leaves the community, the bot will say goodbye and then take itself out of existence.

2025-04-04 11:22:00

- reply

How about this. Everyone who joins the community is assigned a personal bot, call it a concierge spot.

2025-04-04 10:59:33

- reply

What else though I wonder? if the goal is to piggyback off of existing client notifications then the communi-key would have to trigger a notification via an existing pathway (replying to a post, mentioning in a standalone post).
>That message can even be as simple as a reply on the targeted publication event (just thought of that).
But if the failed-validation post never gets published then there's no post to reply to no? I suppose a communi-key support account could simply @mention you with a boilerplate "You tried to make a post that failed..." message, and you'd get notified that way.

2025-04-04 10:23:28

- reply

ATProtocol is too heavy. They've made a lot of good choices, and for certain use cases ATProtocol is the best way to go. There's a lot Nostr can learn from their architecture, if you look at the bare-bones protocol design. (So much misunderstanding here about what the bare-bones protocol is and does.)
But if you need lightness then it has to be Nostr. And for the use case I'm working on you need lightness.

2025-04-04 10:14:25

- reply

Yeah the impact of the sheer size of the cake is a good question, because in some ways that's offset by the relative simplicity if the ingredients. These are pretty digestible json events; the wild and messy internet this is not. I suspect that Primal/Ditto de-facto global fire-hosing infrastructure that's running right now is going to purr along pretty fine even as (if) Nostr starts to scale up.

2025-04-04 10:04:36

- reply

Ah okay, cool, or I guess the communi-key npub could just DM you the notification (or an npub approved by the communi-key to send support DMs could).
On the screening side, I'm not quite sure how much screening logic a strfry relay can be set up to do before it starts to smoke. Or how a strfry relay can be integrated with an external service to handle heavier loads, via those policy plugins and stuff. I'm sure it's all doable though.

2025-04-04 09:22:41

- reply

Thanks for the video, design looks sleek.
So coming back to the example of the text-post-only community; I thought there might be front-end validation in some simpler cases like that, but if all handled by the communi-key then how would that work? The post gets sent and then it's the communi-key's main relay that has the logic to parse the post (does it conform to spec)? And if the main relay rejects the post because it does not conform to spec then that rejection is the basis for the validation-fail notification client side?
Just trying to figure out where the actual computation happens vis a vis screening the event content against the presumably machine-readable spec.

2025-04-04 08:14:24

- reply

Right, just trying to figure out what the ask of clients is going to be. So as someone wanting to post for the community I publish a "Targeted publication event 32222". The client will then need to do a lot of work it seems to parse the content of that event, check it against the community guidelines, and then return some sort of notification if it fails validation.
And before that of course the client UI to generate the targeted event itself (versus a regular note not targeted to a community).
Have you a wire-fame in Figjam or somewhere to show how all this flow would look on a popular client like Primal? Like all the UI elements and backend flows that are not already in Primal but would need to be in Primal this all to work.
https://m.primal.net/QDmv.png

2025-04-03 21:12:12

- reply

How would cross-context communities work. Let's say you've got a group, you can link up with that group on Primal or Jumble, where you talk about some subject, but you can also link up with the same group in a chat app (community channel), or even a shopping app (community discounts), or a gaming app (play with each other) etc. In each context the nature of the community changes.

2025-04-03 20:34:32

I'm torn between this well-thought out list of Nostr breaking changes from @npub1acg…p35c and this well-argued article on not forking the ecosystem that made the rounds earlier.
https://newsletter.squishy.computer/p/dont-fork-the-ecosystem
#nevent1q…mtlr

2025-04-03 08:48:40

- reply

The Ostrich Protocol gets my vote. Easy to popularize, no pronunciation worries, light, and segues well.

2025-04-03 04:32:15

- reply

Dysfunctional interoperability is far worse than no interoperability.

2025-04-02 12:51:05

Communi-keys(tm) by @npub149p…722q (tm) is a good idea, with fair responses to the more obvious devil's advocate lines of questioning. I like the idea that communities can quasi blacklist clients; that would give larger communities some leverage when it comes to policing the community-ordained specs (for rendering and such). Of course a quasi-blacklisted client could still surface content from that community, but there would be no argument that in doing so the client is going against the will of the community's leadership, seeing as it's all there in writing.

2025-04-02 12:33:01

- reply

Makes sense. If a community is large enough that'll also give it some good leverage with clients, which adds some much needed balance.

2025-04-02 11:53:35

Hot take: Bitcoin won't make you happy.

2025-04-02 11:27:53

- reply

I think I'm getting the picture. What about an optional field to whitelist clients that you want the community content to be surfaced by, or blacklist those you don't? Obviously a blacklisted client could still surface the content but then there'd be no arguing that the client is going against the will of the community team.

2025-04-02 10:23:36

- reply

How does that work? How to force clients to get with the program?

2025-04-02 10:22:45

- reply

If feels like Nostr would then... look nice. When I jump from client to client I always get a feeling that videos and photos look like a mess, a hodgepodge of aspect ratios, players, carousel UIs, thumbnail mechanisms, etc. The only posts that look good when jumping client to client are text-only posts.
Not only that but if you live in this text-only world and you have your own relay then that relay *is* your repo. No blossom servers for new users to get their heads around. (Plus just imagine if nostr.build gave up the game tomorrow, what a mess of link rot we'd have.)
And you have an actual marketing hook. Tired of all this media overloading your brain? People too lazy to form thoughts because there are so many media crutches out there? Emojis, GIFs, photos, videos, audio? Come here, a quite text-only world where you own everything and yada yada, AND ZAPs, yada yada.

2025-04-02 10:00:27

- reply

Ah hah, lol. That's a whole 'nother problem.
Pure text. No links. No emojis (except I guess those Japanese ones you make with pure text.) Kind1t notes can quote other Kind1t notes, but that's it, can't quote anything that isn't also a Kind1t note.
But still zaps.
That'd be the dream.
If people need to share links, photos, gifs, they can jump back to their regular Kind1 client and share with the person there. This would be a hardcore enforced text-only world.

2025-04-02 09:48:11

- reply

What did you insert there? Tried a few clients no luck.
https://image.nostr.build/105a3d4869ff9b17ba290814451ace2029d618d4aea5c2c6f9704f7b925f1aae.png

2025-04-02 09:43:56

- reply

Ah yeah, thanks, I played with that before, but it's infuriating because it's not a separate kind. So you still see all the media posts, just that the media is reduced to text links. And then to get the context of what people are talking about you still have to open the media links. So it defeats the purpose for me really.
I'd like a separate kind where every note you see is composed with the composer being fully aware that this world is text only. If you can't say it with text only, you're out of luck. The only way that works is if the Kind is its own Kind and not interoperable with current kind1s.

2025-04-02 08:52:57

- reply

Makes sense over NIP-05 for sure. What about follow lists, could it point to a hosted follow-list (or a list hub in general) a specific relay on which to find it, and client's honour this? Come to think of it why doesn't NIP-05 offer that already?

2025-04-01 15:17:56

- reply

What would we call it?

2025-04-01 14:41:03

- reply

He would agree.
https://image.nostr.build/10cbd108b2d3d40e14c732b2ac25e09b6a5bcc9c1ba8edc272373e9ee366920a.png

2025-04-01 13:54:53

- reply

Good things there are no VCs involved in Nostr then.

2025-04-01 13:31:34

- reply

This is the way.

2025-04-01 13:13:14

- reply

It's a no-win situation. Every time they do come out and state how things are with all the nuance, nobody pays attention. Then they post something for normies that glosses over the nuance and everyone's says they're being dishonest.
https://image.nostr.build/92033c027c7f7838ca405d26bedd559cc495942deb6aaf0dcb2a056a28eca877.png
https://image.nostr.build/3ae17a1ffffa1bf5ed7a265679b64e1213336ca7ed086917a77603f7488a42ca.png

2025-04-01 11:21:16

- reply

But on UX, I'm curious why it takes Primal web longer to load than Jumble web? They've got a big head start in theory.

2025-04-01 10:49:43

- reply

The whole argument for caching was UX. And now I'm using Jumble over Primal web for the UX.

2025-04-01 09:20:21

- reply

I guess so! Or at least opening then doing something their servers are aware of

2025-04-01 09:03:03

- reply

Attention share. Even assuming most people divide their attention between apps, Primal is going to have a pretty hefty chunk.

2025-04-01 08:53:49

Primal pretty dominant share, then.
#nevent1q…dzpm

2025-04-01 06:11:03

- reply

What are Nostr users' thoughts on decentralisation is a good question. If nostr.stats is correct then Nostr just had it's lowest day in four months, i.e. since the start of the winter Nostr has been shrinking. Why then are people leaving? Do they feel Nostr is becoming more centralised? Or is decentralisation a secondary concern, the issue lies elsewhere?
I'm not sure, but if decentralisation were a top concern then we would not be seeing relay usage clump up in this way. At the very least we would be seeing more of a fuss about the state of the relay network and shouts to get Outbox working well. I suspect Bitcoin and social patterns surrounding it are more top of mind for Nostr users than decentralisation, and the reason people are leaving is they are getting a little bored of that conversation.

2025-03-31 19:00:38

- reply

Yeah, flat times. I looked at nostr.band stats just now, and yesterday was a 3 month low. Actually close to the 2023 peak.
The B2B route I think is promising, with this B2B friendly architecture and this candy jar of open source. But attracting regular people to regular Nostr, I'm not quite sure what the best pitch is.

2025-03-31 18:38:39

- reply

>Incentives (and possibilities).
That one, yes, very much agree. On identity, I think the question is if they spin out the did:plc directory into whatever ICANN like body they are in talks with, is that a meaningful change or not?
For me, the vast majority of people who care about ownership in some sense will see that as "good enough" and it will also be healthy for the internet in general. So if they do that—and again the other week they came out and announced the talks have entered some kind of a late stage—then did:plc is basically okay in my opinion. Yes still centralised, but I'm cool with ICANN or whoever else being that centre, so for me that's a meaningful move.
I'm guessing you see this ICANN solution as just moving the centralisation around and therefore not so meaningful, doesn't pass the not your keys test.
Anyway not much more to say about that until they complete the move and it's clear how things will look.

2025-03-31 18:21:11

- reply

Ah hah. Have to say bittorrent has proven a lot more rugged than I thought. If that gets traction makes Nostr's censorship resistance pitch all the weaker. (For me that was never the pitch anyway.)
How polished are the clients?

2025-03-31 17:48:13

- reply

Let's see, if we start doing some good business off these implementations then there won't be much more to say. At that point it'd simply be one of a thousand proven B2B business models and you slowly expand with sales. There isn't anything out there that both covers that particular niche and is as dead simple, and so far we've got good interest and moving to POCs in April.
I'll give you an update come the summer.
I know zero about pubky. Melvin posted about it but I can't parse those. Is it B2B leaning?

2025-03-31 17:24:07

- reply

Matrix we looked at but Nostr events and relays are about as complicated as we want things to get, and this is also more of a Kind1 play. This https://bettermode.com/ is an example of one we were asked to pitch against the other week.
Our pitch is if you're going to be brave, pass over the other guy and take things in house, then you're going to want the most dead simple thing possible. Nostr is pretty dead simple.

2025-03-31 17:00:47

- reply

Give me one recent example of BlueSky making a breaking change to:
app.bsky.feed.post
app.bsky.actor.profile
or any other core lexicon (before the very early days way back).
If you can post the before and after, and it's not two different lexicons, then I'll owe a nice dinner next time you come to Vietnam.
The reason they can't is the domain is just used for publishing at first and for publishing non-breaking changes, after that it propagates. I think maybe you're mixing up the API and the lexicon system.

2025-03-31 16:50:59

- reply

You can't make breaking changes to an ATproto lexicon, that requires a new lexicon. The point about it being a lexicon is that it's not actually a javascript embed (ok calling it an embed type before is the wrong word). You're writing the comment to the PDS in a way that means the comment will be picked up in the additional site(s) where you want it to be picked up, and there's benefit there (versus something like Facebook comments)

2025-03-31 16:34:38

- reply

Cross-company social that functions like email and can also be used by frontline workers and vendors on both sides (those with no basis for SSO). It competes with https://slack.com/intl/en-gb/connect and other offerings. It's cheaper, it's open source, no third party, it's easy for IT departments to understand and with relays on both sides of the fence it can be managed as each side likes. It mirrors email in many ways, and you sell it with email analogies.
Also competes with stuff like https://uintra.com/ but only for the cross-company case.
-Current nostr audience is irrelevant
-Zaps are irrelevant (unless the companies in the mix want them, but we never pitch them).
-The Nostr brand is irrelevant (nobody knows it anyway)
Event+relay architecture w redundancy, keyparis, and the open-source candy jar of client code are all very relevant. Overall lightness is relevant. Clients are custom-deployed from open source (each side has their own client and our team will service it). We plan to use one client codebase for all customers at the start.
Early days and just pitching for feedback but so far is good.
Course none of this is what Nostr was invented for. But if you were going to draft up an architecture from scratch for cross-company social in the vendor age then Nostr is kind of like the thing you'd end up with.

2025-03-31 14:28:00

- reply

Decentralisation is a moving target.
You look at the web itself, it started with a protocol (HTTP) and a single client, a browser called "WorldWideWeb", which they renamed Nexus in 1994 to avoid confusion with the broader concept of the World Wide Web. So the first "WorldWideWeb" was basically Chrome. And that means the web at first was totally centralised. Other clients then appeared and evolved, making HTTP more robust (Line Mode, Erwise, Viola, Mosaic...)
This idea that HTTP appeared and then the web just sort of "happened" on top of it is widespread but totally false.
That's the path ATProtocol has said it wants to go. For that to work the protocol has to get more and more decentralised as time goes by, and that means more and more independent implementations have to appear to take away market share and mind share from the Nexus-like flagship demo.
That's how many decentralised protocols have developed. And the opposite is also true, many protocols that started off pretty decentralised have gradually become more centralised over time (which arguably is what's happening vis a vis Nostr relays if you go by nostr.band stats).
Time dimension is important.

2025-03-31 13:45:11

- reply

>This part is the most egregious, because their "decentralized interoperable identity" is just one server that the Bluesky company hosts. How can that be defended?
Where is that coming from?
Yeah if you sign up on BlueSky's host and never claim your identity then sure, it's on their server. But you can claim it anytime. Their whole philosophy is let the user claim control when they're ready, and in steps. A user can rely on did:web alone for their ATProtocol identity and not use did:plc at all. You end up with a did.json file that conforms to the DID spec w your public keys, your handle (e.g. fiatjaf.com), and service endpoints like your PDS URL, and that did.json file lives NIP-05 style in location on https://yourdomain.com/.well-known/did.json. I get that many people won't claim their identity, but you can claim it anytime. Even if you set up just your web handle (as many users there have done), that's enough to be able to take did:web adversarially later. Once you claim did:web you are fully in control of your identity on the protocol.
If you're talking about did:plc then yes directory operated by BlueSky, though they've announced that's moving out, and my point is that (a) let's wait and see if does move out and where it goes and (b) you don't even need did:plc if you've set up did:web.

2025-03-31 13:25:41

- reply

That's true, but pretty hard to factor human behaviour in to any kind of model. For example a large group on an incredibly boring topic will be less prone to social engineering than a small group on a scandalous topic.

2025-03-31 13:22:49

- reply

Nosotros.app (desktop) is your friend for threads.

2025-03-31 13:12:09

- reply

Client going a little bonkers with replies. Hope this time works.
https://image.nostr.build/7e0d5dd39fb99e0d16d7bbc5bc24a8b5410e85c344a1c4631076d853976054a2.png

2025-03-31 13:01:24

- reply

Not on desktop yet, I think. Desktop version still 1.0.1 from early Jan, and this MLS is like a few weeks old. I've only got it working iOS to iOS (TestFlight)

2025-03-31 12:55:13

- reply

and 0xchat on testflight

2025-03-31 11:59:35

- reply

I also gave up on researching MLS. At the same time @npub1h0u…rwx8 has implemented MLS groups and they work much better than they should at this early stage. I'm starting to suspect that KeyChat is from the future.

2025-03-31 09:30:18

- reply

Ah yeah, there was a discussion I listened to somewhere on that, the gist was that Linked Data is primarily semantic, whereas ATProtocol lexicons are primary schematic. So the whole schematic/semantic debate. I imagine Linked Data can have all sorts of schematic aspects too, but that would be the shoe-horning route, and it sounded pretty convincing to me that such specs should be primarily schematic.
https://youtu.be/JSauiX7XHDo&t=1065
This wasn't the longer discussion (can't find that) but this bit in this video touches on the general debate.

2025-03-31 09:04:36

- reply

Kind of off topic, but I googled Beal and got "He is described as a hoarsely-voiced king with the power to make men invisible and ruling over sixty-six legions of demons."
I definitely think that deserves a trading card.

2025-03-31 08:34:52

- reply

Fake, okay, but fake what? Fake open source? Fake credible exit? Fake announcements? I'm not sure what about it can be described as fake. Are they selling fake Nike shoes in the lobby? And same for scam. Scam what? Are they a front for something we should know about? I get that you mean fake and scam in a poasty sense, but still your "Bluesky is a scam" headline is a little on the tabloid side.
They've always been pretty clear they're going for a more-decentralised-over time-approach. Sometimes when talking to a normie audience they gloss over the nuance of that, but so does everyone.
And it is getting more decentralised. Right now anyone can spin up an AppView lite on a raspberry, connect that to a few PDSs, add a bespoke relay, etc. (No BlueSky company infra in the mix). Enthusiasts mainly now, but that wasn't possible a few months ago. You've got apps going alpha this month like https://sprk.so that’ll be running their own relay/BGS (first publicly accessible relay in Brazil thats not owned by BlueSky) their own AppView, own CDN, using their own lexicon—didn't have any example like that a few months ago. BlueSky just announced they're moving the directory out, which is the last core infra piece still inside. And if you start inside their hosting then it's getting much easier to pull your repo and your keys out now, even under adversarial conditions.
And there are more apps popping up, a lot of which have no crossover with bsky.app. You've got a github clone in pre-alpha, the repo of which you can host on a Raspberry Pi at home https://tangled.sh/@tangled.sh/core. That's a new thing. Other things like https://recipe.exchange/ which use just the ATProtocol identity, have their own lexicon. The https://whtwnd.com/ longform app pulls directly from PDSs.
So quite a lot of "not Kind1" stuff in the mix, and the argument for bsky.app having too much gravity is more of a Kind1 argument than an “other stuff” argument. These apps aren't competing with bsky.app or even using that lexicon (nobody's gonna want their git discussions to show up on their Kind1 feed).
And even for the pure Kind1 stuff there are a good number of new clients now, albeit piggybacking off bsky lexicon, hosting, etc.
Yes the whole deal is way more centralised than Nostr. Yes if BlueSky the company shut down tomorrow without any warning then people wouldn’t have time to pull their repos out. (Though if Damus shut down their app and relay tomorrow without any warning, that wouldn't be chaos free for Nostr.)
But the point is they're going in the direction they said they would go, and a lot of stuff in your “BlueSky is a Scam” article is now out of date. Can the whole thing ever escape its own black hole gravity? Maybe, maybe not. Place your bets. But it's definitely not a silly thing to suggest it might.
Course Nostr is much better for certain use cases. This B2B stuff I'm doing, ATProtocol would never work for that, no average IT department could digest it. But still though, ATProtocol is not a scam.