Was talking with @theycallmedan a couple times last week about COMMUNITIES and I decided it would be helpful to me and perhaps others to take a stroll down memory lane about communities history... and then future.
This is a retrospective view of communities and some of these memories are 2+ years old so I may not remember them super well and since there has been pretty much 0 work on community backend stuff since all the Steemit INC employees namely @roadscape left. This is my post to try to remember all the things we wanted to do with communities but haven't been touched in forever.
I may have some of these memories wrong is what i'm trying to say.
THE HISTORY... from my view
My history of communities is perhaps very different from the developers that actually got it done (I'm not a developer). So take that for what it is.
I remember 2 years ago (this month i think) I was pushing really hard to make communities happen and we (Peak Projects) had been thinking about it for a couple months prior to that, in some way or another on our own platform (steempeak.com at the time). Steemit INC had talked about wanting it to happen for a while before that but nothing (apparent to us) was happening and we knew they had a lot of other things going on and it didn't seem communities was high priority... so we were starting to take matters into our own hands. But it was this month there were some community discord audio shows where some Steemit people like Ned came in and talked about where they stood on SMT and communities and started to talk about renewed interest in communities.
Meanwhile our own team was already talking to a random developer on steem who seemed gung-ho about creating a backend structure and API that would enable communities to happen. We were throwing around a bunch of ideas at the end of 2018 and into 2019 and working with this developer. Hivemind was pretty new and wasn't being used much but we realized that using hivemind to help with this system would be beneficial so we talked to @roadscape. Maybe perhaps our indications that we were just gonna take matters into our own hands was good motivation to get steemit inc to move up the priorities... who knows.
I can't remember all the details but the short of the story is that basically we were told that the backend protocol that steemit inc had in mind to enable communities wouldn't take that much time and perhaps it would be beneficial to wait for it. When it comes down to it we had plenty of other things to work on with steempeak.com (predecessor of PeakD) so waiting wouldn't be the worst thing for us and we much much preferred a decentralized system built on a more solid DB like hivemind would be best for the us and the community.
It did take longer than expected ...We got a taste of communities at that SteemFest in November of that same year and it officially launched about a year ago around this time.
I remember being pretty involved in conversations with Roadscape about what we envisioned for communities, at least by sharing my perspective as a UI person... and then going for long stretches of time not hearing anything about where backend development and where it was at, then to all of a sudden seeing a post about it show up. There was for sure a big lack of transparency and communication between applications, users and steemit inc back in those days that I'm sure i don't have to re-hash. That's why posts by backend developers like @howo and @blocktrades have been so uniquely and wonderfully refreshing i may add. It's such a nice thing to be more involved in the discussion of being able to indicate what apps may need from backend structures... and I'll add that individuals like @howo seem very willing to help make stuff happen even now for communities.
Since @roadscape left I don't think there has been any backend development on community system... that means almost a year?
WHY HASN'T THERE BEEN A PUSH FOR BACKEND WORK TIL NOW?
- On a PeakD front we have had other things to do
PeakD.com can and will be doing plenty of front end changes to community without a need to backend changes. And because there are plenty more front end things we can and will be doing this is part of the reason we haven't pushed for much work to be done on the backend protocols of the the system which communities are built on top of. - Hivemind db was getting a lot of upkeep and advancements so it was prudent to wait.
The @blocktrades team was doing a lot of work to improve hivemind including increasing the scope of what that db does and speeding it up. So it was prudent to just wait until most of that work was done and the db was stable before we started looking at what other things the db could do to help communities
THINGS WE TALKED ABOUT BACK IN THE DAY
This is where i really want to remember all the ideas we talked about... but in the end it's not a bad thing if we forget some ideas because if we don't remember them it may be an indication that perhaps they're not that needed.
But we do come back to a bit of history when we were building the community front end on SteemPeak we were asking for a few things but the basic response was ... let's just launch an MVP (minimum viable product) and then we'll see how that is received and then we'll upgrade from there.
The things that I remember the most...
- There would be multiple types of communities. One community type would allow only members to post in the community. Which should make sense because MEMBERS is a backend feature of communities that has pretty much zero use case with how communities operate right now... turns out members function was developed with other types of communities in mind.
- Another type of community was a community where only members could comment + post. (Aka only members could interact at all with the community)
- We were also asking for other ways to SORT the growing list of communities. Still not sure if alphabetical and chronological sortings are options yet. I think for example we only have one sorting method and that's a unique algorithm that Roadscape created that would sort based on activity and i think it was very rewards based so not even actual content activity but just voting activity. We haven't gotten another sorting algorithm since then even though sorting options were discussed back then.
- Different stats were thrown around but the answer was similar: Let's just go with the ones he developed and see if they're good and see which other ones we should do later. The stats we have right now are mostly ... OK, not really the set I would have personally been excited about, but the idea was to not bog ourselves down into polishing but just release it and then come back around. But we had talked about other stat options for the future and we should look back into that and try to remember or perhaps just think of what stats about a community would be the most useful.
SO... WHAT CAN WE DO WITH COMMUNITY PROTOCOL
(love to hear your thoughts)
- I think we should for sure allow a community to indicate that they want to be member posting only.
In a way that's essentially like them saying everyone is muted in the community except for those on the Member list. Remember that the community structure doesn't actually prevent someone from posting or commenting what it does is more 2nd layer... it impacts the API from Hivemind and so if you are muted by a community (through moderators) then those posts just won't show up. - Then of course give communities the ability to indicate they only want members to post + comment.
In the end a community is a location where an owner (or group of designated people) choose their own rules and have tools for moderation. So we're just giving them a couple other rules to choose from... assuming it is what is best for their owned community. - Is there something that can be done for users to indicate they want to be a member? Put themselves into a queue where the moderators can decide which subscribers should now become posting members?
- I think we should have multiple sorting options for communities.
(There are thousands of communities but only one way to presently sort them and I am not convinced it's the best way to sort them)
A: The obvious sorting options and probably easy ones are Alphabetical and Chronological.
B: But sort by number of subscribers would perhaps be even more useful.
C: Or perhaps number of total posts... or number of posts in the last 30 days.
D: How about sort a community by the number of users who have posted or commented in the community in the last 30 days. (I'm using 30 days but maybe 7 days is sufficient... in the end it would be nice if the protocol allowed a front end to make 7 or 30 an option) - STATS are a fun area for discussion and it would be interesting to hear what users would want to know about a community when making a decision about a community. Or what a community owner would want to know about their own community. I have some communities and this is what i would want to know.
A: How many total posts are in the community.
B: How many total posts written in the last 7 days ... and not posts as in comments+posts but just posts only because we want to know what actual articles will be new not just that one user happened to have a post with 50 comments. (which hopefully isn't too hard for us to figure out.)
C. How many unique users have written a post ... and perhaps in the last X days. (That seems to me to be a better way of seeing how active the community is... because when it's about comments we don't know if the community itself is active or just that a user has a good following and that user had followers that interacted who could care less about the community)
With a few more stats then front ends could extrapolate those stats as well... perhaps give some posts/week formula for the community. Or interactions/week (posts+comments) - We (peakd.com) would really love to be able to classify each community by theme/topic so that we can present new (and old) users with communities related to topics they tell us are of interest to them. So it would be a very good time to allow the community to identify X number of topics their community is related to. Perhaps 3 or 5. The number could be debated. It can be an open system where a community could put whatever they want. BUT perhaps a front end could help the communities to choose from a list of common selections. Like ARTS/SPORTS/BLOCKCHAIN etc.
This would also be helpful when helping to sort communities as well. But mostly helpful to help present a new user with a list of Topics, Communities and maybe even Users that relate to subjects they like. - Classification of Post types.
This actually is not directly related to the community backend... but i want to throw it in because of how big of an impact it can have on communities and benefit to Hive in general. By classification of post types it means: being able to classify if the post is a VIDEO or PHOTOGRAPH or ORIGINAL CONTENT or LINK SHARE or SHORT FORM.
That means our users and communities could have tons of tools built for them directed at a particular type of content (if you filter them by those forms you essentially have a feed that rivals youtube, instagram, twitter etc). A community for example could have an area that is twitter-esque or another community could have a section for Videos. In general you'll see that most sub reddits and communities elsewhere on the internet is comprised heavily of sharing content made elsewhere communities on hive may have a very hard time thriving if there is no good system for allowing link shares. Obviously how to treat them in regards to reward pool is another question altogether (they should indeed be treated differently) but allowing the backend structure on hivemind is certainly the first thing to do and I submit that communities will never be quite near as successful if they don't allow for sharing outside content. - Since we are already talking about non community related changes to Hivemind let me throw in another. Language classification of a post... it has already been discussed in the hive core developers meeting but just bringing it back up. Communities have a language indicator already but this is about having it on posts. Putting it into a post metadata is not hard but Integrating it into hivemind would be needed to make it more useful. So instead of getting 1000 posts from the API and then doing a filter process to see which ones are Italian (and find out only 1 is) if it were built into Hivemind we could do a request to the API and pull up the last 100 italian posts directly.
- Then the final non-community related request to make communities awesome is to find a way to make private communities... but that requires figuring out how to do Encryption/Decryption here on Hive and that's not a small undertaking i'm guessing. @howo and @blocktrades also once talked about this request of mine back in a Developer meeting and mentioned some ways they thought it would be possible.
Anyway I don't think this needs to be done first... i think we get the rest of the stuff working first then try to tackle this. But it's not just for communities but now that automated payments are coming out we are close to pay-wall / patreon sorts of solutions... however those types of users usually want a private (encrypted) sort of option. (Maybe even something off chain or second layer... but the important part is decentralized aka not a specific front-end dependent)
RECAP
- Different types of communities
- More stats about communities
- More community list sorting
- Classify communities by topics/themes
- BONUS: classify types of posts, language support in hivemind and encryption
Thanks for indulging my stroll down memory lane and sharing some things that could be helpful for Hive communities. PeakD.com is gonna focus heavily on communities and we think as far as social media aspect of Hive that communities is the biggest and best feature. We have seen how much movement to communities is happening to communities since it started. It's a powerful thing and I think the timing is right to put more focus to them and start upgrading the backend will be awesome.