This would be a massive change - both conceptually and literally.
In a sense it would redefine the project, since presently it is "asocial". meep is not supposed to be federated - at least not in the sense that if I set up an instance I can hook it up to yours. Is there a sweet spot between individually hosted servers and
Reasoning
It allows people to more easily use meep; at the moment, someone has to be tech savvy enough to set up server, install meep, configure it, and get it running.
Multi-user capability means that I could set up a small meep instance for my circle of friends, or for a small focused online community.
The first and foremost would simply be https://meep.social, which is presently rather unused. It could still serve as a landing page for the project, and maybe stream.meep.social would be a publicly available meep instance solely for the project's updates.
To be clear, a multi-user instance would not necessarily mean that it includes things like replying to posts from other streams. (Though that does seem to be the next logical step, which is a great bit of scope creep.)
Pitfalls
This definitely does open the door to scope creep: a small circle of friends quickly grows to wanting to connect that circle to another circle, and so forth. Suddenly meep is Yet Another Social Network. The defense against this, for starters, would have to be saying no to a lot of requests for people wanting meep to be something it is not.
Beyond scope creep on the project level, it would also lead to a lot of scope creep on the feature level. As already mentioned, replying to one's own posts leads to wanting to reply to other meep stream's posts. That leads to a social network.
Another pitfall is that a multi-user environment means that users are beholden to the config set by their admin (at least partially). Hosting your own instance means you're in control, so if you want to create long-ass blog-length posts, go for it, it's your world. But if you sign up for a multi-user instance that places a (reasonable) restriction on post length,
Moderation is a huge issue to face. Making registration a manual process would go a long way toward keeping things like bots and malevolent actors from posting, but I can see how many people would hate that idea. But automated registration is a clear example of being opposite to meep's goal - to be small, to be intentional.
Many other pitfalls not listed here, from security to privacy to infrastructure; would this whole markdown-based thing even scale? Oh god, I used the "s" word...that's not good.
Reflection
The more I write about it, the more I feel that it is just antithetical to meep's mission statement: be small, be asocial, do not be a social network.
So I have to ask myself, what problem would multi-user capability actually solve?
First problem it would solve: making meep accessible - and not just to the nerds. The problem to be solved is "how does someone actually use meep without having to do all the nonsense I do just to host it?" and I don't have a clear answer. That doesn't mean that "I'll just host everyone's instance" (effectively what a multi-user solution would be) is a good answer.
Second problem it would solve: creating more of a community. I love the idea of small intentional online communities as opposed to giant ones filled entirely with strangers. (That's what everyone flocks to Discord for, even though I maintain it's a suboptimal choice for that, because it's presently the best choice. Which is sad, but I digress). But as I type about this, I realize that that goal is just beyond meep's scope: that would require supporting uploading images and videos; loading previews of links; probably privacy settings or private messages.
Conclusion
After reflecting, the real problem I still wish to solve is making meep accessible, and I should try to think of a creative solution to that problem that fits in line with meep's mission, instead of jumping to what everyone else does.
The requirements for a meep installation could be greatly simplified (get setup with cargo binstall, get CI set up for Releases for use with tools like Distillery, have some sort of prompt-based wizard to set up config, providing systemd and other configuration files, have a theme-chooser [as soon as there are multiple themes], integration with certbot for SSL certs, etc). All of that should be done anyway.
But it does not change the other non-meep side of the task: setting up a server for meep to run on. And, if the user will want to use a PWA, setting up a domain for it. This problem I cannot find a way around, aside from providing very good documentation (as opposed to what I have now). And even then, it's still not accessible to people who are not willing to learn a bit about how to set up a DigitalOcean droplet and configure DNS.
I see two potential options:
- Provide my own hosting for people (but not as a multi-user instance)
- Connect with some service like PikaPods or Cloudron, which would allow for 1-click deploy (and hopefully both SSL and PWA)
I'm not sure how I would do both of these, and my head hurts, so I'm going to stop for now.
This would be a _massive_ change - both conceptually and literally.
In a sense it would redefine the project, since presently it is "asocial". meep is not supposed to be federated - at least not in the sense that if I set up an instance I can hook it up to yours. Is there a sweet spot between individually hosted servers and
# Reasoning
It allows people to more easily use meep; at the moment, someone has to be tech savvy enough to set up server, install meep, configure it, and get it running.
Multi-user capability means that I could set up a small meep instance for my circle of friends, or for a small focused online community.
The first and foremost would simply be https://meep.social, which is presently rather unused. It could still serve as a landing page for the project, and maybe `stream.meep.social` would be a publicly available meep instance solely for the project's updates.
To be clear, a multi-user instance would not necessarily mean that it includes things like replying to posts from other streams. (Though that does seem to be the next logical step, which is a great bit of scope creep.)
# Pitfalls
This definitely does open the door to scope creep: a small circle of friends quickly grows to wanting to connect that circle to another circle, and so forth. Suddenly meep is Yet Another Social Network. The defense against this, for starters, would have to be saying **no** to a _lot_ of requests for people wanting meep to be something it is not.
Beyond scope creep on the project level, it would also lead to a lot of scope creep on the feature level. As already mentioned, replying to one's own posts leads to wanting to reply to other meep stream's posts. That leads to a social network.
Another pitfall is that a multi-user environment means that users are beholden to the config set by their admin (at least partially). Hosting your own instance means you're in control, so if you want to create long-ass blog-length posts, go for it, it's your world. But if you sign up for a multi-user instance that places a (reasonable) restriction on post length,
Moderation is a _huge_ issue to face. Making registration a manual process would go a long way toward keeping things like bots and malevolent actors from posting, but I can see how many people would hate that idea. But automated registration is a clear example of being opposite to meep's goal - to be small, to be **intentional**.
Many other pitfalls not listed here, from security to privacy to infrastructure; would this whole markdown-based thing even _scale_? Oh god, I used the "s" word...that's not good.
# Reflection
The more I write about it, the more I feel that it is just antithetical to meep's mission statement: be small, be asocial, do not be a social network.
So I have to ask myself, what problem would multi-user capability _actually_ solve?
**First problem it would solve**: _making meep accessible_ - and not just to the nerds. The problem to be solved is "how does someone _actually_ use meep without having to do all the nonsense I do just to host it?" and I don't have a clear answer. That doesn't mean that "I'll just host everyone's instance" (effectively what a multi-user solution would be) is a good answer.
**Second problem it would solve**: creating more of a community. I _love_ the idea of small intentional online communities as opposed to giant ones filled entirely with strangers. (That's what everyone flocks to Discord for, even though I maintain it's a suboptimal choice for that, because it's presently the _best_ choice. Which is sad, but I digress). But as I type about this, I realize that that goal is just beyond meep's scope: that would require supporting uploading images and videos; loading previews of links; probably privacy settings or private messages.
# Conclusion
After reflecting, the real problem I still wish to solve is **making meep accessible**, and I should try to think of a creative solution to that problem that fits in line with meep's mission, instead of jumping to what everyone else does.
The requirements for a meep installation could be greatly simplified (get setup with `cargo binstall`, get CI set up for Releases for use with tools like Distillery, have some sort of prompt-based wizard to set up config, providing systemd and other configuration files, have a theme-chooser [as soon as there are multiple themes], integration with certbot for SSL certs, etc). All of that should be done anyway.
But it does not change the other non-meep side of the task: setting up a server for meep to run on. And, if the user will want to use a PWA, setting up a domain for it. This problem I cannot find a way around, aside from providing _very good_ documentation (as opposed to what I have now). And even then, it's still not accessible to people who are not willing to learn a bit about how to set up a DigitalOcean droplet and configure DNS.
I see two potential options:
1. Provide my own hosting for people (but not as a multi-user instance)
2. Connect with some service like PikaPods or Cloudron, which would allow for 1-click deploy (and hopefully both SSL and PWA)
I'm not sure how I would do both of these, and my head hurts, so I'm going to stop for now.