Nostr Web Client

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: https://github.com/nostr-protocol/nips/pull/2106.

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:

https://github.com/coracle-social/metamanager

https://github.com/coracle-social/website

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

Constant 1mo ago 💬 2

Why shouldn't client devs run a relay? Lets go a step further, why shouldn't they put the relay they run as the default for their client? Because i think they should, or atleast its fine if they do.

Ofcourse users should be able to change settings/relays or whatever Nostr-virtue, and ofcourse there should be no hard tie in between the client and relay in terms of functionality and whatever Nostr-sin you can imagine. But giving users basic onboarding both in terms of giving them a relay to start out with, as well as some content to look at, makes sense to me.

Could be any kind of relay, for instance something like spatianostra based on a group of trusted users.

Reply to this note

Please Login to reply.

Discussion

Dawn 1mo ago

It would be neat to see client specific dynamic voting. Each client that chose to implement something like that could sort of display their own community ethos to new users by seeding it with pubkeys that have supported their project thus far. It takes some time & attention from a few foundational voters to build a feed that is viable, but spatianostra itself could act as a somewhat neutral placeholder until a client specific instance was built up to something satisfying to the client developers.

hodlbod 1mo ago

An important premise of nostr is interoperability, both in technical and social terms. If clients don't run relays their defaults have to be provided by a third party, reinforcing the social cobtract that if you run a relay and don't actively protect it, anyone can connect. Like how opening a connection to port 22 is legally considered hacking, but opening a connection to 443 isn't. It also distributes risk posed to the user and encourages technical ibterop as well.