Do you want a Hive Community where Only Members Can Post?

avatar
(Edited)

That's coming, in case you didn't know...

But, as far as Hive Communities Design tells us, there will be a catch.

You have to decide what kind of a Hive community you want from the beginning. Once you decide, there will unlikely be a way to change your mind or change it at a later date, because the type of your community will be hard-coded in the name of the community owner account.

Until now we have only seen in action one type of communities, the one referred to as "topics" in the communities design. And we have 548 of them at the time of writing this! Not sure if they are all functional though, because if you attempt to create an owner account with a proper hive id username but outside the Hive communities interface, you end up with a regular account on Steem, unlinked to the Hive communities.

In the topic communities, anyone can post and comment, including non-members (i.e. guests).

But the design speaks of two other types of communities:

  • journal - only members can post, but guests can comment
  • council - only members can post or comment

Here's a relevant quote:

All communities and posts are viewable and readable by all, and there is a governance mechanism which can affect visibility and prioritization of content for the purpose of decreasing noise and increasing positive interactions (however a community wishes to define it) and discourse. By default, communities are open for all to post and comment ("topics"). However, an organization may create a restricted community ("journal") for official updates: only members of the organization would be able to post updates, but anyone can comment. Alternatively, a professional group or local community ("council") may choose to limit all posting and commenting to approved members (perhaps those they verify independently).

So far the Steemit wallet interface only allows someone to create topic communities, even if you don't know it.

There's no way around it on the Steemit interface or on the blockchain to create other types of communities until they are supported by the communities interface(s), because the Hive communities are part blockchain (owner account + other community accounts, posts, votes, comments), and part centralized database and Hivemind/communities code.

Just in case you are not convinced, I tested it:
image.png

I created outside of Hive communities (i.e. outside the steemit beta interface) the Steem account hive-21112, which should correspond to a journal-type community. But it was created outside the Hive communities, and the Hive code doesn't know it because there aren't any Hive database entries corresponding to it. So, if I try to check out the "community" later in the beta interface, it tells me it's an "unmoderated tag" as you can see above.

I've read there are community managers who would be interested to switch guest posting (maybe guest commenting too) on and off through the admin interface. By looking at the communities design this seems an unlikely option. And I don't believe it would be easy to redesign this, maybe that's the reason why the other two types haven't been released yet, in case the need for a a more flexible solution is under consideration.



0
0
0.000
10 comments
avatar

So why would switching guest posting/commenting on and off be difficult to implement? I couldn't understand.

I understand the Communities design specifies that each type of community starts with a different number (1, 2 or 3). I am not sure why that is needed - maybe to maintain consensus? (i.e. it's a way to represent the community's permission levels on the blockchain rather than just in the Hivemind database.)

If it's for consensus purposes, then I'd imagine there would be ways to update the piece of information on the blockchain that specifies the community's permission levels.

Or maybe there's an entirely different reason.

0
0
0.000
avatar

Well, as far as I understood it, the whole point behind the design was to separate the three types of communities through the naming of the owner account, as you remarked the initial 1, 2 or 3 after hive-.

The difficulty comes from the fact a community has only one owner account, and you can't change the name of an account on Steem.

So, that road is closed to change the type of the community, after it is created.

There needs to be a redisign in order to make this happen. Either that, or add additional blocking mechanisms to more permissive communities, but that makes the need for the initial design kind of pointless.

I am not sure why that is needed - maybe to maintain consensus?

Hive communities don't need consensus, they work on a higher level above the blockchain.

(i.e. it's a way to represent the community's permission levels on the blockchain rather than just in the Hivemind database.)

Good catch! I don't know why it was chosen to represent the type of the community at the blockchain level. Maybe to make this verifiable outside the Hive context?

0
0
0.000
avatar

Yeah, that's my understanding of what they call "soft consensus" - you put the data on the blockchain so it can be verified by others (instead of having a smart contract on the blockchain that does one verification for everyone). So everyone can verify that a Hive community starts with 1, and therefore what is allowed and what isn't.

But maybe @roadscape can chime in and let us know about the design of Hive communities and the possibility of changing their type or permission levels.

0
0
0.000
avatar

But maybe @ roadscape can chime in and let us know about the design of Hive communities and the possibility of changing their type or permission levels.

If he has time sure, I know he reads posts in this community.

0
0
0.000
avatar

These types are still planned, but currently disabled. Type 2 ("journal") is almost ready, and considering adding a new requirement for Type 3 ("council") -- that all payouts must be disabled.

0
0
0.000
avatar

Thanks for replying Tim!

About the potential new requirement to disable payouts for "council" type communities, would they affect the payouts in SMTs, if a community decides to have one which would practically be closed to members only? Or that would apply only to the STEEM reward pool?

I'll be a kind of a messenger here with a question, if it's ok with you: will there be room in the future development of communities as you envision them for what I've seen requested a few times, the possibility to switch guest posting on and off within a community?

0
0
0.000
avatar

About the potential new requirement to disable payouts for "council" type communities, would they affect the payouts in SMTs, if a community decides to have one which would practically be closed to members only? Or that would apply only to the STEEM reward pool?

Good question. Ideally this would require disabling STEEM payouts only. I guess it depends on SMT implementation. But currently this is achieved by setting max_accepted_payout to 0.000 SBD, and I don't think its likely that this will apply to SMTs, because it would be complicated to get the market value for each, especially when many will be illiquid. So I think we're good.

will there be room in the future development of communities as you envision them for what I've seen requested a few times, the possibility to switch guest posting on and off within a community?

We'll have new community types which restrict who can post, but I don't think we can have it be editable at will. At least not initially. There are edge cases to consider for the backend, and the goal is to keep the protocol dead simple (and efficient) for now.

0
0
0.000
avatar

There are edge cases to consider for the backend, and the goal is to keep the protocol dead simple (and efficient) for now.

I agree! Plus there's the expectation, which with more work being done before the "official" launch, will make people anxious.

But it's great there's the longer term perspective for who's interested: :)

At least not initially.

Nice to hear about new types of communities too.

0
0
0.000
avatar

Love to hear a discussion going on about these other potential community types and enjoyed hearing @roadscape talk about how they're coming along for the backend.

Thanks for spreading awareness.

0
0
0.000
avatar

Yup, I'm a big fan of communities. I think they are a game changer for the regular users. SMTs too, through the potential effects, but not something a regular user can grasp as easily as communities.

0
0
0.000