Feedback: to see an example one has to click through to another file in the repo.

Is it a subset of Markdown or YAML? It is a type of decision that it would be good to be upfront with to the users. It also gives you a framework for further thinking and development, and some out of the box parsability.

I don’t know if you’re talking in the long campaign, same players context, but I often find that for one shots around half of players, at best, skim the rulebook of the particular system. Myself sometimes I do, sometimes I don’t find time. Some people, like it or not, come to a session mainly to chill and even let the others do most of the adventuring. Others engage with the adventure but don’t feel like engaging with the rules beyond what the GM requires.

I’m also assuming the GM will explain the rules, and I think they are the ultimate authority. So stuff from the rulebook may not even be relevant (thrown out, replaced), and GM is the interface for the rules. I would call it OSR mentality, though some may call it glorified player laziness. But as a GM it may give you more room for your ideas actually.

I think the situation is a problem if players don’t know the rules and get mad when their plans are impossible. I suppose this can happen more often with rules-heavy systems.

Anyway, I think keeping the rulebooks close to the players (either as putting them on the table or sharing PDFs) is good advice.

Agreed, I think hosting it on localhost not exposed to the internet is a great idea if this satisfies your needs for now. Do double-check the docs for your system if firewall disallows web server connections by default (Manjaro and Endeavour are based on Arch which is supposed to have good wiki).

Then, if you want to go online, you can export the database and put it into a server install.

Corps passing their stuff as “technically open source” would also be a problem. Google controls a lot of web by open source Chrome, Microsoft controls dev IDEs by open source VS Code. I’m sure OpenAI would find more ways to pretend to be “open” again if it would be more profitable than saying they have scary monster AIs they can’t release publicly.

Open source exceptions would have to be in tandem with breaking them up somehow and setting some limits to their activities.

Yeah, I’m not disagreeing there is a convenience and ease angle, but I think there’s a middle ground where we have 2-3 communities for major interests with somewhat different vibes or approaches, so there is a topic reason for them coexisting. This already happens in the old school forums ecosystem. Fediverse’s advantage here is that you hopefully don’t need separate accounts.

Re: loss of knowledge, if some instance/community does a purge, I’m assuming the old posts are still there, at the very least on the instances that used to be federated with them. I suppose it would be a nice to have a feature for admins for “freezing” their public backups of mirrored communities when they get defederated. It’s not that different of a scenario from standard Internet drama, we just have to handle this nicely.

I agree with other people that the right to defederate is to be respected. If we rely on one hub community somewhere to congregate, this is only kinda decentralization. At the very least the central hubs shouldn’t be on instances that are too defederation-happy.

On the other hand, I see the argument that many users means more difficult moderation, where defederation might be a band-aid as they say on beehaw. The question is if they have too ambitious moderation goals to handle being a central hub, and maybe indeed it would be better for their communities to be sort of internal to them.

May be worth keeping some local communities in that case, which can also serve as sort of backup for wider community from other small servers. For example, if there is “Knitting” on a big instance, you can consider creating something more specific like “Knitting full RGB sweaters” on your smaller instance. Then there is a basis for sustained discussion there, and more people can come if something breaks. I have some ideas for comms like this that I’ll maybe come around to creating.

I don’t think we need to keep full centralization be-where-everyone-is mentality here. Or maybe be where everyone is, but don’t make it the only place where you talk with people.