microblogging (backends)

we could use Hometown until GoToSocial offers local-only posting, and then move across. Hometown needs at least 2 GiB of RAM; GoToSocial only a few hundred KiB. Hometown will also consume more and more and more and more storage space, unless we turn away media attachments coming from other servers, or someone pulls off some other trick.

16 Nov 2022

i think a local-only default/option for posts is a must. the huddling in amongst ourselves outside more public gazes is also poss w slow shell media, but i figure some people would strongly prefer a more web2.0y setting for doing so?

first problem: most web twopointohhy platforms demand lots of power, storage space, etc. both to browse/use and to supply/maintain. (haha see bookwyrm, previous scheduled post).

[one popular platform] is in some respects less excessive than most, but would take tinkering with to permit the huddling. it also appears associated with sketchy sketchy politics, to put the vibe mildly. i wouldn’t want to depend on such a world for help with muddling through. wouldn’t really want to entrust dearest friends’ data to this software anyway/either. even if the code were guaranteed eternally fine, it would be realllly baaad if people lookin into one of their communities’ most prominent tool were met with racist abuse or terf propaganda or other personally horrid material in the space of a couple of clicks. so flat no i’d say from what little i’ve observed.

Hometown? lovely! number one desired special feature taken care of already and for probably a good long while into the future. but this is a variant (“fork”) of Mastodon that differs from the original only very slightly, so is big, structured to handle massive loads, and relies on lot of other software. following the official installation procedure, i ran out of disk space compiling the language mastodon’s written in (uh, ruby, i think it was?)… therefore trying mastodon-based approaches in a straight-forward manner will likely entail installing it on a larger-capacity (temporary) server.

further to hometown, feelin inspired by how Queer Haus have made it their own… might be worth thinking about adapting some aspects of their fork ifffff they’d be okay with that?

or what about GoToSocial? sounds virtually perfect? no need to use mail, even. still early days though; local-only posting not practicable yet. most features have to be used via a mobile app or an alternative frontend. fiddly (for me) finding ones that are compatible with both gotosocial in its current alpha state and my esoteric browsing behaviours… dug around the source and stumbled across a template for out-of-band client authentication (i think?), though, so mixing and matching might (already? soon? eventually?) be more flexible than initial experiences suggest. and most people are not me. on the admin side, setting up a test gotosocial instance was an absolute breeze. development roadmap (plus receipt of a grant) suggests (all going well) should be easy to migrate an entire community from hometown to a fully fledged gotosocial in a year or so. or we could ride out the alpha/beta stages all the way? should i whip up a spot you can try it out, regardless?

working title snailspace

28 Nov 2022

biggest problems continue to be power demands (processing, electricity, etc), storage burden, and safety.

GoToSocial (GtS)

not too bad on the power side. keeping in mind i’ve only been one person, trying it out a few times a day. the gts server software seemed more than happy with under half a gig ram and whatever my v.p.s.-provider’s base level processor option is. currently it’s sharing an entire gig of ram with 1) my usual stuff (website, gopherhole), and 2) a bookwyrm (b.w.) instance that’s as close as it gets to at rest (though b.w. is meanwhile automatically scouting its known network—of a few hundred people scattered over about two dozen other bookwyrm sites—for new users and stuff still, and runs scans for things to flag for moderation so far no wuz). in this arrangement, gts’s share bobs around 10 per cent of the ram, 0 to 20 of c.p.u.


i browsed around via gts, and in so doing have federated with around a hundred other servers and encountered profiles and posts originating from a few thousand accounts. presently, my GtS media cache is cleared out daily—aside from profile pictures and those banner-ad–like header images that commercial socmed made popular. looks like those two remain on file permanently, for every account from which the gts server has ever received these? currently strangers’ (usually frightfully high-resolution) pictures are taking up 1.8 gig. you can imagine what a crisis such endless amassing could build to over time. there may or may not be convenient ways around this. i would hope, being into lower resource-usage, the gts developers would gladly introduce some controls on the profile-banner-problem if asked? though how quickly who knows.

the limits on size of media uploads from local users are adjustable; i set them way down from the contemporary norms and yeah sorta i wish everyone would. the ~​~​~​user experience​~​~​~ of having your photo rejected when you forget to resize it first should NOT trump the ~​~​~​user experience​~​~​~ of stupidly huge copies of things choking up ever more room and passage, whether that frenetic dance out from constriction is ~​~​~​unseen​~​~​~ in ~​~​~​~​~​the cloud​~​~​~​~ or starkly palpable tryna network in a friggin warzone or live amongst encroaching tide lines or whatever.

safety: so far i have no concerns specific to GtS, other than local-only posting not being implemented there yet.

Hometown (ht)

power: oy. at this stage i am one person trying it out next to not at all. on a tiny operating system, one miiiight get hometown or mastodon to start up on half a gig of ram, but not on my v.p.s.-provider’s fairly stripped-back blend of debian. it periodically conks out processing new block-list additions (scarcely applicable to the mere dozen accounts it knows) on a whole gig of ram. on the bright side, this has taught me a smidge about tempering the ambitions of postgres (the software that mastodon-derivatives (and, actually, bookwyrm) rely on for their databases), for playing more nicely on modest systems. one gig of ram was not, however, enough ram to compile the version of ruby in which hometown is presently written (despite being adequate for the ruby to which mastodon has since upgraded). anyway, i got there eventually. but i thought bookwyrm was egregious? hohohoo. it will be interesting to see if diverting hometown log-ins through an alternative interface, like brutaldon or pinafore, can help at all. at least on the user-end.


hometown/mastodon hoards profile pictures and banners with the same zeal that gotosocial does. however, admins can already instruct ht/m to reject all media from particular domains.

domain blocks in mastodon (and therefore those in hometown) cover all subdomains: for example, if an instance silenced posts from “breydon.id.au”, this one restriction would apply to the test bookwyrm on kwyrm.breydon.id.au, test gotosocial on dondon.breydon.id.au, and test hometown on homet.breydon.id.au, as well as any other ridiculous trials i conducted round there in the future. what that means, it turns out, is that i can tell hometown to reject media from “social” and it will not store pictures from any domain ending in “.social”!

periodically ensure you’re doing the same for all top level domains recognised by IANA and (assuming no elaborate set-up incorporating unusual domain resolution providers), that presumably means no surprise masses of piccies or videos clog up your server! downside is they won’t appear directly in your feeds, either. though here’s hoping alt text still does. should do. and (some? all? most? depends?) stuff should still be available for individual viewing by clicking through to its source.

the immediate community members’ media meanwhile would work as normal: stored on their communal server, turning up in each other’s feeds, and, when attached to federating posts, being sent out to people further afield via other people’s servers.

treating (audio)(visual) data like this is arguably a radical take on social media? but i think there simply have to be some sort of volume restrictions in place for community-run social media to remain affordable, for an internet in general to ever approach anything remotely like even a temporary ecological feasibility, or for any kind of computer-facilitated communications to be truly accessible ~​globally​~.

there would be other benefits: vastly reduced chance of unwittingly harbouring child porn, for instance; softened confrontations with untagged graphic horrors or ill-timed NSFW refreshes of one’s feed; less sluggish scrolling; lower drain on mobile batteries and download allowances; potentially some reduction in compulsive allure…?

however, it could be somewhat harder to host the likes of zine club from a server that won’t unhesitatingly relay photos from just anywhere.

(i wonder if there’s some way we could selectively cache media from communities known to keep file sizes reasonably efficient?)

and not that there’s much getting lost in the crowd when coming from a tiny instance, but individual access to ~​~​content​~​~ would become that bit more starkly trackable. (in practice there’s no substantial anonymisation of any kind of resource-access over present-day ActivityPub, as far as i am aware (which is not very far at all anymore). in some cases, you could avoid your instance authenticating with an interesting adversary’s server by—from elsewhere—subscribing to an r.s.s. duplicate of the public portion of their activitypub feed and relaying it into some secret bot account you followed, but…)

anyway, limited inline imagery: what do you think?

safety: currently, blocking the dodgy is SLOW and AWKWARD on hometown, but i get the impression it’ll offer a neat means for moderators to process block lists en masse sometime ~​soon​~. (the GtS alpha already has this feature. mastodon took until version FOUR. (hometown is presently based on masto three).) the mastodon project has for years been knowingly neglecting user safety (especially for BIPOC). hometown inherits many of mastodon’s shortcomings, but does try to compensate. there’s talk now and then hometown might eventually have to split off completely.


might tease some things out in a separate post later? maybe. tired brain. catch yous later.

please bombard me with opinions if you have any wish to
working title snailspace

12 Dec 2022

  • GoToSocial will be able to keep its own header hoard in check from some time in the new year!

working title snailspace

your responses