Hi! We've got Forum-Style channels planned, similar to Discords, would that work for you? It'd still be a single text channel, and you could have multiple of them per community.
The comments are not trees like Reddit. It's more like a list of questions you click into for a thread. Basically a channel where the top level is a list of threads, has more permanence than threads in normal chat channels.
Fair point! A different user has already pointed out that this isn't disclosed enough on the landing page, and I'll be adding a section to clarify that, both on there and in the app itself.
I think one of the replies here already linked the current proposal for private data spaces, which I'm hoping will become implemented later this year. At that point, people will have the option of either having their community be 100% public, or confined to a more Discord-style data storage, where people can still join, but not everyone can "just read" the messages
Just want to chime in with, this does feel very slick, but this was the #1 question I had. I could not determine it from your site, and had to try it out to see.
One major criticism of things like Discord is that they're private, so I don't think that it's inherently disqualifying, some people might even prefer it for that reason. But it's very, very important that you're very clear about this, up front.
We've taken a look at co-supporting ActivityPub as well actually! And yeah, the fragmentation is an issue. But I honestly think we might see at lease some level of interop between these fragments in the coming years, even if it's just some parts of the protocols and specs going in the same direction.
Your own messages are on your PDS. The chat, the category, community and all metadata are stored on the PDS of the person who created the community. The chat is then displayed via our app view, which keeps a live index of all messages and provides some endpoints to collect them!
> But that’s not where you want your chats now is it? E2EE? And how does it keep it all private since apparently the Bluesky bros haven't figured that part out?
It honestly depends. Right now, Colibri is meant to function for communities that are public anyway. If you're a streamer, an open source dev community, Colibri can help you with talking to people who don't want to be locked in by big corporations. As the E2EE and private data, the Bluesky people have posted a new proposal for that only a few days ago, which I'm already thinking about how to implement: https://dholms.leaflet.pub/3mhj6bcqats2o
But, yes, for now, chats are public. Private data will hopefully be a thing soon on the network.
This probably needs a bigger callout. A user who isn't familiar with ATProto doesn't even know to ask this question and the design space from its contemporaries (e.g., discord, slack, etc) suggests that chats are nominally private if folks aren't a member of the channel.
It's a very cool product but you have to let people know their messages aren't private.
Thanks for the quick fix :) Nice to see more Discord alternatives these days.
A few other landing page issues if you feel like addressing them:
- Attempting to navigate with the Tab key results in tab order following nav elements once, where focus indicators aren't visible, and then the same elements get iterated over again but this time focus indicators are visible.
- Tab order doesn't include screenshots and jumps to the FAQ
- Clicking a thumbnail shows the larger image but without any elements for closing the overlay
The problem for atproto will be getting a permission system that can enable enough parity with Discord that it has a competitive experience.
I was working on this, taking a break from atproto, re: bluesky "leadership" who defacto decide what does and does not get into the protocol via the PDS used by 99% of users.
Hi! We're doing that to allow you to update your profile from within the app. Not doing anything else besides that. If you have concerns, take a look at the source code:
https://github.com/colibri-social/colibri.social
From a product uptake perspective, I could suggest that since a user is still building trust when they begin use - to only require as few permissions as needed. I'd punt that profile update requirement out personally for another method later.
An example might be when a user has used your app for N sessions, or after N months.
They should prompt the user for permission when they use a feature that requires it, explain why, and allow them to cancel if desired. Have seen this pattern used many times elsewhere.
reply