I'm incredibly tempted to make my own custom chat group. Besides the fact that Slack and Discord annoy me, dogfooding is really key, and this sounds like a fun and worthwhile project to keep me connected and energized to my product.
As I discussed in #7, I don't think I'll be able to build a secure enough chat app in v0.2 (without server side code running) but I can get started with v0.1 and find little hacks to build around it...
Or just go for v0.3 asap. It'll probably just be another couple weeks past v0.2... Pushing back the launch date a month doesn't sound right however when I can just setup a Discord in 2 minutes... On the other hand, I personally really dislike joining new chat groups. I think it'd make a huge difference to immediately get to read the chats on the same site, embedded within the page. The lightweightness of it is important to me.
Custom Chat App Design
Purposes
See if the Compose has a vibrant community. I don't know if this is common, but I often finding myself looking for real and current social proof that a tool is worth my time. If we can somehow communicate that lots of people are talking about it every day, that would be awesome.
Introduce yourself. I think it should be default to introduce yourself before you're allowed to post. I want everyone to see that a new community member joined, but also be able to filter these out and maybe peruse them in batches (or never).
Get realtime help on coding issues. I think this will be the main workhorse. I want this "channel" to be lively 24/7. Potentially I'll be manning it for the start. I'd be open to paying people to man it, but I can also imagine people would be into manning it just cause it's fun to teach others. We can make a system similar-ish to StackOverflow or r/changemymind where you can reward answerers in a structured way for good answers or help. We can then reward top answerers with badges or even tangible prizes like equity in the company.
Share your work. A maker community thrives on showing off work to each other and getting high-fives. We really need to set a culture of ensuring that people really cheer each other on – not just post their own shit.
Create long-term, search-engine-indexable public artifacts a la StackOverflow. Slack and Discord definitely don't have this feature. I guess StackExchange is the closest to what I'm thinking of.
Show that the Compose can be used to build real things. Walk the walk. Dogfood to keep myself connected.
Experiment with end-programmer programming. See if/how to get people to customize the code both within the community (superficial changes) and via total forks to start new communities (new database).
Find a job. Maybe I'll build a custom job board in Compose too! (Or could just use pallet.xyz)
Data model design
I'm highly biased in favor of infinite nesting a la Twitter/HN/Reddit. What I probably want is something a lot like Twitter in that any message can have an option parent; and "channels" are added to messages via hashtags. In this way, there's really one feed, but you can slice and dice into channels after the fact. For us, the supported tags will be something like:
introduction
help
demo
I think for starters, messages can only be part of one channel. The design will borrow from HN/Twitter/Reddit for collapseability of infinite threads.
There will also be a way to send DMs or private group messages.
Scalability
Already I'm worried about scalability, but I think it'll be ok because (1) I can create manual indexes if necessary (won't be fun but will ease pressure), and (2) it'll be a "great problem to have" (at which point I'll presumably have $$ to throw at it) and will motivate a more scalable ORM version, which users will want anyways eventually too.
On compose.run
The embedded community should convey vibrancy over all else, and I think the best way to do that is to prioritize recent messages of quality. I think it should show something like 2 recent #help threads and 1 #demo thread, but only threads with at least 1 reply. It should then allow you to view all messages or filter for each channel, possibly by linking you out to community.compose.run.
On community.compose.run
If you're logged in, it should show you your notifications or just the main thread (no filter). Filters can go in the URL bar so you can bookmark what homepage view you want.
Search
This sounds tricky to do fully within Compose, but of course users will want it eventually. I guess I'll start with the stupid simple JS way and see if I can switch to some AWS service or something or another abstraction when the scaling starts to kill me.
Search-engine indexing
I guess this means I'll probably need some sort of NextJS Server Side incremental static generation of Compose components. Yikes! But also a great problem to have to work through, as others will want it to -- eventually.
Notifications
The default setting will only email you for replies or DMs. Then maybe once a week a digest of stuff I write by hand.
You can sign up to be notified by arbitrary queries too. Would be awesome if you could write the query in JS!
I'm incredibly tempted to make my own custom chat group. Besides the fact that Slack and Discord annoy me, dogfooding is really key, and this sounds like a fun and worthwhile project to keep me connected and energized to my product.
As I discussed in #7, I don't think I'll be able to build a secure enough chat app in v0.2 (without server side code running) but I can get started with v0.1 and find little hacks to build around it...
Or just go for v0.3 asap. It'll probably just be another couple weeks past v0.2... Pushing back the launch date a month doesn't sound right however when I can just setup a Discord in 2 minutes... On the other hand, I personally really dislike joining new chat groups. I think it'd make a huge difference to immediately get to read the chats on the same site, embedded within the page. The lightweightness of it is important to me.
Custom Chat App Design
Purposes
Data model design
I'm highly biased in favor of infinite nesting a la Twitter/HN/Reddit. What I probably want is something a lot like Twitter in that any message can have an option parent; and "channels" are added to messages via hashtags. In this way, there's really one feed, but you can slice and dice into channels after the fact. For us, the supported tags will be something like:
introduction
help
demo
I think for starters, messages can only be part of one channel. The design will borrow from HN/Twitter/Reddit for collapseability of infinite threads.
There will also be a way to send DMs or private group messages.
Scalability
Already I'm worried about scalability, but I think it'll be ok because (1) I can create manual indexes if necessary (won't be fun but will ease pressure), and (2) it'll be a "great problem to have" (at which point I'll presumably have $$ to throw at it) and will motivate a more scalable ORM version, which users will want anyways eventually too.
On compose.run
The embedded community should convey vibrancy over all else, and I think the best way to do that is to prioritize recent messages of quality. I think it should show something like 2 recent #help threads and 1 #demo thread, but only threads with at least 1 reply. It should then allow you to view all messages or filter for each channel, possibly by linking you out to community.compose.run.
On community.compose.run
If you're logged in, it should show you your notifications or just the main thread (no filter). Filters can go in the URL bar so you can bookmark what homepage view you want.
Search
This sounds tricky to do fully within Compose, but of course users will want it eventually. I guess I'll start with the stupid simple JS way and see if I can switch to some AWS service or something or another abstraction when the scaling starts to kill me.
Search-engine indexing
I guess this means I'll probably need some sort of NextJS Server Side incremental static generation of Compose components. Yikes! But also a great problem to have to work through, as others will want it to -- eventually.
Notifications
The default setting will only email you for replies or DMs. Then maybe once a week a digest of stuff I write by hand.
You can sign up to be notified by arbitrary queries too. Would be awesome if you could write the query in JS!
Alternatives