I love both projects, they are cool and necessary, but they seem still in the experimental phase and are not ready for someone who needs a tool immediately ready for use, and it's not primary interested in exploring a new protocol.

I just opened them again after a few days, and I cannot browse anything, 3 of 4 groups don't load and are empty for me (like the two links you shared), I got connection errors... it's a little mess. I'm doing something wrong? Idk.

Btw, some suggestions:

These clients should have a clean "Create your group" landing that doesn't expose random servers/groups but just lets the user create a new space by picking a public relay, or entering a personal one. Some basic information about features and Nostr itself, and a link to a how-to article, would be great, too.

The actual app's interface should be designed first for a *single* space, allowing the user to explore the advanced features (searching groups on the networks, creating their own group) with a progressive discovery pattern. This limits confusion and errors, and most importantly, it gives the impression, both to the group owner and their users, to have a real *personal* and confined space, like they are used in the current website/forum paradigm, even if they are guests in a public server.

Then, for this last reason, it would be really useful to have an advanced guide to set up a personal relay *and* a personal frontend client; the latter should have the option to be graphically themed, to selectively enable specific features/areas (rooms, posts, pools, calendar, ...) and to hide all the other servers/groups stuff.

Users will then find out that they can easily switch clients, discover Nostr interoperability magic, and so contribute to the growth of the network/protocol.

/cc nostr:npub1jlrs53pkdfjnts29kveljul2sm0actt6n8dxrrzqcersttvcuv3qdjynqn nostr:npub107jk7htfv243u0x5ynn43scq9wrxtaasmrwwa8lfu2ydwag6cx2quqncxg

Reply to this note

Please Login to reply.

Discussion

I agree there are bugs everywhere, but we can't say phpBB doesn't have bugs either. That thing is basically a living bug.

I disagree with hiding relays, relays are the most important thing in case of groups. If we hide that we're left with nothing. But I do think it wouldn't hurt to have some defaults hardcoded.

Incidentally I think the relays point wouldn't be that bad if we had the "single space" flow, but in a different client -- not Chachi or Flotilla -- that could operate on a single relay. Perhaps exposed as an HTML page in the relay URL itself, where people could go and create groups or just browse the group if it's in unmanaged mode.

After using groups in this single space flow for a while users could transit to the more featured clients.

> exposed as an HTML page in the relay URL itself

I also was thinking about that to facilitate the custom setup.

Embedding Chaci/Flotilla in a khatru relay is really easy; at the end you just deploy a single binary with an config file and maybe some assets (about page, logo, etc) to hot overwriting some client stuff.

You know, I'm for advertising the relay concept as much as possibile, but sometimes we have to choose a priority. Someone who is searching for a new home for their group is not left with nothing, but with a clear path on how to build that home.

> different client -- not Chachi or Flotilla

They both can have a setup flag to manage a single relay, when self hosted.

> After using groups in this single space flow for a while users could transit to the more featured clients.

This is exactly my proposal.

In the case of microblogging apps I think the relay concept can be hidden for a long time for new users, actually, as long as outbox works.

But in the case of NIP-29 groups I don't think that should be an option, because you are trusting a server, so you must be forced to at least acknowledge that a server exists somewhere.

The relay is primarily important for the group creator, that should be aware of what he is picking up, or what he decides to self host. Final users just want to focus on the content.

Here we are talking about a specific use case for NIP-29: create a personal and branded community.

If I join my hamster group, I don't care to see a dropdown with random servers or rooms about other topics, I just want to focus on my little friends.

The only server I want to see is the group's one, that in the best case should match the website and so the related NIP-29 client.

The current state of Chachi / Flotilla is more like a IRC client, it's absolutely fine for many users and needs, but it's conceptually a totally different tool.

The good news is that with very little additional effort, the clients we are talking about can serve both solutions.

I'm talking about the group creator all the time!

And I'm taking about the main interface all the time. As stated, the group creator must understand clearly that he is picking a public relay, or that he can opt-in for a self hosted solution.

Great feedback as usual. The bugs you mention are a show stopper for apps like Flotilla and Chachi and we should squash them, make sure the onboarding is smooth and the chat UX is great. I have also thought about streamlining group/wallet creation for people that just want to use it and not necessarily care where data/money is, making some choices for the user while giving them control if they need it. I'll do this and I'm already doing a lot of work (bugs, perf issues) to get out of the experimental phase.