microblogging (backends)

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.

storage:

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.

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.

storage:

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

GtS’s dvelpmnt roadmap (as updated middish thuis year)
shows it on track for a beta release early in 2024.
it’s already incredible for alpha software —
but the beta will let us be as selective as we want
about which other fediverse sites can network with ours,
and, even if we do engage with others
on the beta version, we will be able to have huddle‐only posts.

however,
i have started thinkg bout
setting up a widely‐federating, alpha‐version GtS server
under a snail subdmoain

for:

• behind scenes nittygritty process chronicling ¹ i’d begun elsewhere & still keep on snuddle webste ²
• eearly adopters try out / congreg on, as we done(&doing) w/ wlybsmwai
• long term accounts people want widely reacchable

?
?
?
(if any of these are things you’d want…?)

to exist alongside !
in futre

selectively federating (or zero fed / private),
beta‐version GtS server
uner a differet snubdomain

latter being what id envizh as
the main huddle‐microblogging space,
what i’d be more fond about keeping (that is: takng care of) longer term

orig thouht of a sole GtS server
exising as “micro.snailhuddle.org” ³,
but will need two distinct subdmns if
embark on a { widely fedrtg / alpha / interim } supplementary GtS srvr ⁴

maybe “garden.snailhuddle.org” for the more insular?
being somethig of a walled garden?

maybe more gregarious GtS server
should have name other than “micro”,
to reflfect its more publically‐reachable–ness?

(“sea.snailhuddle.org” i’d be inclnied to reerve
for somethig to do with scuttlebutt protocol)

we couuuuuuuuuld keep using the blocklists and interim policy dcuments
that have been applied to wlybsmwai so far and seemin ~​adequate​~ there

however the mainstream, non—circum–book‐niche fediverse
is oders of magnitude more harrassment vectory.
so we’ need t be careful,
and prepared to bail right on out of the public‐alpha‐server trial
should need (or simply want) be

feelings?

i conceive of snailhuddle as spread across at least two computers
(for certain definitions of “two” and “computers”, and “snailhuddle”)

that way if, say, BookWyrm’s one has a spectacular crash,
leaving https://book.snailhuddle.org down,
the info on https://snailhuddle.org can stay up independently of that

it’ll also make for a smoother experience for those of us
who decide to havea go at playing around
tending personal homepages or enjoying terminal‐based games
or acquiring new puter skills, or whatever,
logged directly into snailhuddle “shell” accounts
— because the snailhuddle computer we’re doin that on
won’t be preoccupied with the strenuous business of web 2.0

question is,
do we plonk the gotosocial happenings
on the same machine as the bookwyrmage?
(in which case if that comp gets overwhelmed
all its web 2.0 socmeds go down or get slow at once)
or?
(in which case rental costs be higher
or we sacrifice shell smoothness — imean
GtS is efficient
but not impossibly so!)

and do we have GtS use full‐on postgres database(s)
alongsdie bookwyrm doing so? or sqlite for GtS data?

and anothernother question —
of so much less consequence — 
is if two GoToSocial servers (could)
end up running on the same computer,
how do we (and more to the point the computer)
refer to them (internally) without clashy ambiguities?
maybe names along lines of “garden-gts”?

---

working title snailspace
would i guess become
WorkingTitleSnailspace