invis
@invis
This page's posts are visible only to users who are logged in.

xn--hs8h
@xn--hs8h
This page's posts are visible only to users who are logged in.

gretchenleigh
@gretchenleigh

I have architected and managed infrastructure of similar scale, and this is all spot on. Running a place like this is hard, and massive kudos to @staff for building this and making it work for so long. I’ve worked on many projects that would dream of ever being as successful, often with far more resources available.


You must log in to comment.

in reply to @invis's post:

as far as “misuse” of open‐source software by “bad actors”, i wouldn’t be terribly concerned about right‐wing knuckleheads trying to spin up their own cohost instances, personally. in practice, the only undesired use i ever seriously worry about is a military using open‐source software to kill people; i don’t think any military would ever have any interest in cohost.

i don’t have any other commentary to offer on this proposal other than that it all sounds very interesting and potentially feasible.

Each Cohost instance can elect its own moderators and its own system administrators, and run it using volunteer labor with a reduced risk of burn-out.

unfortunately, in the eyes of cohost's funder, it seems like this proposal would be considered DOA (emphasis mine):

[...]it's more like a matter of whether any future continuation of cohost is going to be serious about user safety and community moderation, and I think the fact of the matter is that this can't be done on a volunteer basis.

also, some of my own thoughts:

to me, the points on federation particularly sound like we're getting far enough from what cohost is now that we may as well just start something completely new. federation isn't really the easiest thing to just tack on to an existing codebase - there's likely fundamental changes to data models etc. that has a decent chance of being harder to add in after the fact than just starting from scratch. obviously i can't say for certain that's the case without the source code, but big sweeping changes to the backend like some form of federation would often involve a lot more work than one would expect

This doesn't feel particularly "modest in scale", it's a harsh turn that would require re-licensing code, untangling a lot of the infrastructure, changing the development structure and process, potentially developing a lot of new stuff, and of course this wouldn't pay the bills. While not impossible, this seems like a lot of work to, at best, have something called "cohost" still up and running.

agreed - OP has, i fear, underestimated the scale of this proposed implementation. your remark about 'something called "cohost"' also feels apt - this proposal seems transformative to the point that the final product is simply not Cohost but something else.

i actually don't hate the limited federation proposal - just not for Cohost. although it does sound a bit like its just standardised blogs with RSS feeds, and a reblog functionality built into the blog.

in reply to @xn--hs8h's post:

I do wonder how a federated approach would hold against flag-bombing-style attacks, malicious mass-report floods.
So far I don't think I've seen anything of the sort land on cohost - which isn't to say it didn't happen, I don't have that insight of the @staff - but I haven't heard of any individuals being targeted in this way and taken down, which says a lot.

Having reports move across channels, between disparate teams with mixed experience, and through federation may open new avenues for distributing, even amplifying, the harassment such an attack would carry, through the actions of other instances' moderation teams.