Here are some things I'd like to see from the Square/CashApp team for making this stick. I'd hate to see merchant adoption stall again, especially when we have to tools to make it an every day thing: - Onboarding resources for "local guides". I am enthusiastic enough to actually go talk to the businesses in my area about accepting bitcoin, but a really crisp value proposition for businesses would be helpful (fees? UX? treasury?) - A referral program for people doing the boots-on-the ground work of onboarding merchants *and* onboarding customers. Both sides of the market have to be developed at the same time, local "guides" are indispensable for stuff like this. - A clear articulation of the value prop for customers. You don't pay card fees when you pay, and you have to pay fees to get bitcoin. What is going to make customers want to pay to convert fiat into bitcoin, only to give it away to merchants? There has to be a clear story here — maybe a 1% discount merchants can offer? I think this is a huge opportunity to move bitcoin into "medium of exchange territory" that we should be sure to avoid wasting. If Square/CashApp can leverage the enthusiasm of local bitcoiners to help nurture the network effect, that would be a huge success. @jack @MT⚡️ @miles 🌞 View quoted note →

I spent some time this week writing a new key rotation scheme for nostr:

GitHub

NIP D8 Key Rotation by staab · Pull Request #2114 · nostr-protocol/nips

This removes the time delay required by #829 by introducing a new single-purpose "migration" key. Users can set this up in advance, store...

I think it's pretty good for what it is (it improves on @PABLOF7z's version by not requiring an arbitrary time delay). At the same time, it's riddled with very fragile assumptions about events being available, introduces a hard dependency on OTS (or some equivalent), and requires clients to constantly compute key validity. At the end of the day, what I have learned is that we probably can't realistically do key rotation on nostr in the application layer — we need some kind of cryptographic magic or strongly consistent data store to make it happen. It still might be an interesting read for the nerds out there though.

Double buffers are one of the coolest programming techniques, and are relevant more often than you would expect

This is pretty funny View quoted note →

@nigini pointed UCAN out to me this morning, which is an interesting protocol for bearer token authotization. I can imagine this being useful for nostr, but I'm not sure exactly how yet. Maybe a better way to do relay authorization or social circle-type features?

GitHub

GitHub - ucan-wg/spec: User Controlled Authorization Network (UCAN) Specification

User Controlled Authorization Network (UCAN) Specification - ucan-wg/spec

View quoted note →

Ok, so apparently auto-deploy was turned off on Flotilla web, so if you've been confused as to why there aren't any new features and everything is broken, try a hard refresh and look again.

Returning to a project I haven't touched in two months:

Aaaaand 1.5.2. If your rooms are missing, you should update. View quoted note →

Flotilla 1.5.0 (and 1.5.1) is out! This release leans into rooms by implementing the various access control flags defined in NIP 29 and in this PR:

GitHub

Build software better, together

GitHub is where people build software. More than 150 million people use GitHub to discover, fork, and contribute to over 420 million projects.

I've added support for room policies and member lists to https://github.com/coracle-social/zooid, which is getting closer to a stable state. Also noteworthy are the addition of space membership lists based on the newly merged NIP 43 for proper two-tier access controls. Most exciting though is the launch of https://hosting.coracle.social, which allows you to set up your own hosted community relay. I fully recognize my own hypocrisy here (I've long said that client developers shouldn't run relays), but I also recognize that it's easier to monetize hosting and support than client software, which I very much want to do in order to help nostr become self-sustaining. To reduce the coupling between Flotilla and Coracle Hosting, I've added a list of hosting options to the "create space" page which lists several alternatives: I've also open-sourced the infrastructure that powers Coracle Hosting, so you can run your own version of it! If you want to be listed, please contact me and I'll add you to my hosting services page. Here are the repositories in question:

GitHub

GitHub - coracle-social/metamanager: Community organizer onboarding app intended to be deployed alongside zooid

Community organizer onboarding app intended to be deployed alongside zooid - coracle-social/metamanager

GitHub

GitHub - coracle-social/hosting: A form for signing up for coracle hosting

A form for signing up for coracle hosting. Contribute to coracle-social/hosting development by creating an account on GitHub.

The neat thing about metamanager is that it includes a chat bot which allows admins to manage virtual relays from a NIP 29 room. This way, Flotilla (or your preferred groups client) actually becomes an admin dashboard! With all that out of the way, here's the full changelog for this release of Flotilla: * Restyle mobile dialogs * Add room membership lists * Add space membership lists * Add edit room form * Support closed/private/restricted/hidden rooms * Add hosting services page * Improve performance and UI * Fix push notifications * Improve error detection and handling * Support invite links on discover page * Add link to landlubber if user is admin * Clear reply/share/edit on escape