running our own BookWyrm site is viable. it requires 1–2 GiB of our servers’ RAM to itself. BookWyrm works well with or without email access. however, avoiding email could effectively prevent us from resetting forgotten passwords. our instance of BookWyrm — We Loved Your Book So Much We Ate It (WLYBSMWAI) — has been live since the beginning of 2023.

16 Nov 2022

i’m lightly torn between proceeding with BookWyrm or relegating such things to e.g. a gem(ini) ring/feed/collab/app thing or something?

bookwyrm currently very inefficient though likely to improve to some unknown degree

most of bookwyrm documentation assumes use of Docker (which comes across as probably a slimy stealth-proprietary con, to me), though there is just enough info provided that i could probably cope running it dockerless, hooray

kwyrm presently relies on sending automated emails to establish new user accounts, which is… a nuisance/nother (ongoing) expense (rentin some outgoing-mail server).. but then again select-programmes-being-able-to-send-emails is likely to come in handy? otherwise i don’t know maybe one could behave very daringly directly in the bookwyrm database?

i think i will try stoking up a test bookwyrm on my own (first admin account doesn’t require email apparatus) and see how that goes. if okay, then i might hook it up to a mail server i managed to contrive earlier this year, and test in a more complex manner. if still all good and anyone else interested, then can come a real attempt, probably outsourcin emailing to a (more dependable!) server-for-hire

working title snailspace

19 Nov 2022

incredibly, i have had some success!

bookwyrm’s installation guidance is, uh, a little sloppy; plenty of little mistakes or out-of-datenesses or unspoken assumptions to scramble over, requiring some picking of new ways through.

so i ended up starting a new v.p.s. (virtual private server; pretend computer on, in this case, somebody else’s computer). that reduced the number of tangly problems to consider at a time.

eventually i got it mostly working: ipomoea.breydon.id.au

what i haven’t been able to solve is that if the v.p.s. reboots, i have to restart the bookwyrm software manually, but that’s not too bad, i suppose? (something to do with the daemoniser systemd not getting the system user that runs bookwyrm properly settled into the python virtual environment (venv?) that bookwyrm should be run in and then as a result the python web server gunicorn (accidentally outside of the venv? inside it??) not knowing how to find the python module bookwyrm, as far as i can tell????? doesn’t sound quite necessarily right, but i am not in the life/mood to study the idiosyncrasies of python.)

having a separate v.p.s. will keep costing unnecessary money as long as it’s up, so i then tried afresh on my usual v.p.s. (eruca, if you’re wondering). because i already use that server for other domains and subdomains, bookwyrm had to go behind a reverse-proxy this time. i’d written myself out some speculative instructions, and surprisingly the only tweaking they required was the correction of a few silly (and thankfully very easily spotted) typos. will be hanging onto those! (my instructions, not the typos).

this is much nearer to how a communal server would be set up, mainly differing in address: kwyrm.breydon.id.au

they still need to federate with other bookwyrm instances, though. as far as i can tell, that may just be a matter of time and usage? searches for myself from either server show me on the other. it’s possible to view a few profiles associated with remote instances. follow requests and direct messages appear to send but go unreceived. ipomoea lists kwyrm among its “federated servers”, but kwyrm hasn’t reciprocated yet. so attempts at interinstance interaction between accounts are falling flat.

there is no way to test interaction between users who share an instance yet, because there really doesn’t seem to be a faculty for offering more than one account per instance without the bookwyrm software successfully emailing people. (except maybe by turning on open registrations and turning off the need for confirmation emails? but i’m not in a hurry to try that on the internet!)

i will leave both instances running for a while to see whether they link up a bit better. quite possible, given they have the opportunity to retry their background doings now that neither is getting regularly switched off in my impatience. hopefully i can dismantle ipomoea within a few days with all concerns abated. fingers crossed there’s not some reverse-proxy–related problem interfering with ActivityPub (the standard that the instances use to speak to each other).

not sure i will bother trying to get bookwyrm to send email via my own email server (aboard the good ship v.p.s. lepidium, for those still playing along). i’m almost certainly going to have to devote yet another short term v.p.s. to nutting out a successful installation of mastodon and/or hometown (tried it on lepidium, got too unwieldy)… and that’s just too many v.p.ses, when i’m not particularly happy with how the email one is organised anyway. but i’m feeling fairly confident that bookwyrm itself is unlikely to present huge obstacles to hooking it up to a reliable s.m.t.p. service when needed.

the next big bookwyrm pickle could be trying to update the software without relying on the docker shortcuts. but it looks simple enough to figure out. related might be customising appearance (logo, stylesheets) and stuff (??), and the question of retaining these alterations after software updates. probably already accounted for by mouse the maintainer in how the static files are stored and generated, i imagine.

er, so yeah. we can have a bookwyrm, if any of youse want. and we can almost certainly decorate it to taste.

working title snailspace

20 Nov 2022

ipoTEST.png image: cropped screenshot of the Ipomoea TEST bookwyrm instance homepage, featuring a nineteenth-century woodcut of a sweet potato. the engraving appears in three sizes. at its smallest, the sweet potato has been greatly simplified into a favicon.

  1. imagery in place! ready to endure the rigours of a software upgrade sometime.
  2. feared something was terribly wrong with ActivityPub and ports and the reverse proxy, so i experimented with configuration of the “kwyrm” instance… and found uh, no it had probably been fine? ish? but things (tonight) are nonetheless often VERY slow and crashy, which is a shame.
  3. follow requests, direct messages, user profiles and book data are popping through (apparently) no worries now in all directions between ipomoea.breydon.id.au, kwyrm.breydon.id.au, and bookwyrm.social!! (and in the case of user- and book- database entries, definitely well beyond; i’m not going to try pestering other account-holders anywhere tho) annnnd…
  4. so is inTRAserver interaction on the “kwyrm” one! (boy am i regretting how ambiguous that name makes that instance to speak about). becaauuuuse
  5. i managed to cheat the system! it’s multiuser now!!

an admin can generate invite codes, and give them to people. who can then attempt to sign up using an invite code. after which the admin can look up details of pending registrations, including the confirmation codes bookwyrm tries to email. if the admin then tells a user-to-be the confirmation code to use, the user-to-be can complete their first real log-in with that, thereby becoming a user-to-bean!

note that from the prospective member’s perspective, the website fails at least a couple of times during this, as well as lying about an email having been sent. but! ultimately the process still works!


working title snailspace

22 Nov 2022

  • yep data seems to endure. had to dig in source code to find how to do routine procedures associated with updating, because again, all the documentation is presupposes docker. but yeah no, doable enough. (and if we lose everything, we lose everything is, admittedly, somewhat my attitude lest i inadvertently strike with the unpreciselyforeseen)
  • ((((actually it’s probably an invaluable safety catch, that the software’s interlocking processes collapse to nothing when called as a systemd service; bookwyrm’s quite the hydra already, and its worst struggles will fully lock up the entry of interruption commands, necessitating a (cringe!) forced shutdown. in those extremes, it’s good to get a breather on the reboot.))))
  • oh the THEORIES i came up with in the back of my day-to-day mind as to why the extreme crashiness… but ultimately… it was purely ‘cause big fragile cobblings strewn into life out of sprawling roiling toy library scripting language universes unto themselves tend just to devour memory! i strategically upgraded eruca from 512MB of RAM (shut up) to a stab-in-the-dark choice of 8GB for half an hour of furious queue-processing and…. glitches nigh clear melted away. it’s been holding uncomfortable-steady since while sporting one singular gig of RAM. half that’s been an absolute embarrassment of riches for serving my usual static files to a minute audience, mucking around with littler software, and peering at a single-user GoToSocial experiment on the side, but an idling BookWyrm alone I think reeeaally wants nearer to 2.
  • importing yer old reviews from, for example, goodreads might be more demanding (from what i hear), but er, i haven’t got any such history to experiment with, so frankly, if anyone wants to do that just tee it up with me in advance so i can give the RAM another boost for you? i suggest we leave the import form closed most of the time.
  • turns out even silly workarounds aren’t needed to safely sign up to bookwyrm without it emailing you! if settings are toggled in the right combination, admins can generate invitation codes to give out and invitees can redeem them without any further confirmation codes coming into things at all. the only remaining question here then is how can you reset your password if you’ve forgotten it? the only proffered mechanism relies completely on automatic email for verification. maybe the email-generating could be rewritten to a spitting out of a link behind the scenes for admins to pass along? iuno. tssmooth otherwise.

gosh that’s about it from me about bookwyrm, and reading-specific discussion/tracking/sharing tools in general, for the moment. so i will shut up! hooray!

over to you :))))

working title snailspace

ooh hey hey hey, thinking: what if i opened us up our actual BookWyrm for real in advance of everything else, (hopefully?) in time for those of you who'd like a shot at tracking your reading across the whole of the coming year?

it would mean:

  • you'd probably want to write down your password somewhere you can find it (at least until there's a password-resetting mechanism in place)
  • committing to the snailhuddle.org address, 'cause once the bookwyrm is live it cannot be shifted to a different domain
  • jupming right into a subdomain for our bookwyrming (e.g. book.snailhuddle.org — but if you have alternative suggestions please please have at it!)
  • using an interim privacy policy (the one on my test run is simply "Won't be snooping.") and code of conduct (such as the placeholder i've slapped on test socials, which reads as below…)


the following conditions apply to both local account-holders and visitors. that includes all people, all organisations, and all tools engaging with anything or anyone on this server.

  • fostering the likes of racism, ableism, classism, casteism, islamophobia, antisemitism, cissexism, heterosexism, misogyny, eugenics, and xenophobia is unacceptable, on any scale.
  • do not harass, abuse, stalk, dox, threaten, coerce, bully, or intimidate people.
  • except for informing moderators of inappropriate behaviour - to quote, reproduce, or adapt any post or attachment, you must first have received its author's express permission.
  • follow bots; url shorteners; spam; surveillance; data monitoring, collection, analysis, or trading; crypto mining; unauthorised scraping; and other greedy, misleading, or intrusive applications of technology are forbidden.
  • please keep attachment sizes small. nah, smaller than that. thank you.
  • no police. no commercial interests. no internet of things things.
  • content may only pass to, through, or from this server if it can be stored on here legally.

access may be suspended on these or any other bases. but let's still try and do better!

cool, thanks!

and unfortunately later finder out abouter ers will not have the opportunity to join in so soon but hopefully they will forgive my extremel
y slow progress through terribly limited access to most means of possibly getting in touch with anyone in recent (and not so recent) times
and enjoy whatever the earliers start establishing
working title snailspace
and of course if you decide nah after trying it for a while that would be fine! no grand pledges expected

10 Feb 2023

2023! means the snailhuddle freestyle bookclub is online

it is called "We Loved Your Book So Much We Ate It" (for the wild things card story [at 26:50–27:48 of linked recording]​)

to quickly differentiate from sites using the standard bookwyrm logo, i took a photo of a newsletter that had been dined upon inside my letterbox:

bsho_large.png image: printed matter which has been subjected to a voracious readership of actual snails.

i started sending out invitations at the new year. invite links lead to an account creation page. once an invitation link is generated, it cannot be (readily?) cancelled, so i made the links valid for only one account each. (the options were for one five ten twennifve fifty ahundred or unlimited). there was not much choice of expiry date, either: the account-making windows last a day, a week, a month, or indefinitely. so i chose the month length, figuring the others far too impractical.

this was, of course, more than a month ago.

at which time i didnt finish contacting everyone i would like (love!!) to invite!

and i am very sorry i have been unable to properly convey my enthusiasm and appreciation at your responses!

if you want in and are not yet please pester me no end in case i cannot reach your earlier correspondence :')

11 Feb 2023

ooh dear the older invite links1 are telling people:

Permission Denied

Sorry! This invite code is no longer valid.

(or equivalent in translation)

whichhh feels a bit brick-wally to me! has anyone else found this? i'm so sorry!!!!

the site description is displayed afterwards, but the formatting on this page is not amazing for incentivising reading down it all; it's a lot of scrolling to get to my message "If your registration link has expired or otherwise does not seem to work, please request another." but that is a strange line to lead with in all other contexts.

worse, there is no link or explanation as to how one might go about requesting another, unless you happen to navigate to the homepage and come across the "Request an invitation" form2. of course, you can bypass the form and just use the power of conversation or correspondence, but…../i/ to whom it does not even apply find the above notice discouraging and automatically wonder if it's due to a deliberate, quiet revocation of welcome !! an encouraging nudge from the interface feels called for!

the "no longer valid" rejection is identical regardless of whether the link has been used up through the creation of an account3 OR expired through disuse4. so any change to the text is going to have to account for at least those two possibilities….. i could tryn improve it as a huddle-specific fix, in the short term, but not for every bookwyrm-supported language setting! i think i'd like the "Request…" form to be provided right there on the error page, though can see possible downsides to that too. (and it's definitely more python-code–wading-through than i have the capacity for anytime soon, to put it there myself)

one to notify the developers of, do yous reckon? and in the meantime, could changes to the site description ease the impersonal apparent-rejection? or….pictures could be slipped in above the text…could a visual help (some)?5 or sommmmething?

what is uppppppp with tumblr's what-should-be-blockquote formatting (and tumblr's everything)

12 Feb 2023

"please request another" in the site descrip is now a link to the first field of the request form…. because that is the nearest relevant anchor point available for hyperlinking to (https://book.snailhuddle.org/#id_request_email).

on small displays6, this will lop out of ~​view​~7 (unless you scroll up, but why would you?) the text saying what that field (and for that matter the overall form) actually is.

folks logged-in at the time of link-following will just be sent to their usual home timeline page, which is an opaque behaviour still tbqh but hopefully not too disruptive.

unsure whether this is truly better than nothing.

as always, suggestions welcome.

your responses





invite processes initiated by request form submissions operate separately to invitations admins generate spontaneously, because the system assumes it can email them out itself once approval is given. but we could use whatever the user conveys through the "Email address" field (whether an email or other means of contact) to supply a link manually. the admin interface in this case, then, cannot be relied on to know something has been sent or not; i am depending on a handwritten list at the moment to keep track of links/allocation/expiration, but provision for notes kept in the database and displayed in the admin view would be better once this role is shared with multiple people!


keeping in mind i am only issuing single-use links (as a security precaution)


again security-wise, keeping the window open indefinitely does not strike me as too great. even if the risk of stolen invite codes is low and spam accounts easily deleted, the administrative clutter of still-active invite codes mounting up is liable to lead to confusion/mistakes… and "low risk" is not "no risk", especially over unending time spans! a friend telling me ages down the track that they'd like a replacement invite seems to carry more obvious legitimacy than an account appearing in a friend's name as a result of someone redeeming an ancient invite code. i dunno. what do you think!


reckon pics should be supplement not centrepiece to communicating message tho; too easy for them not to make it to the viewer in the intended fashion (irrespective of measures like alt text).


and on large ones, ifts still poss to be scrolled past the top of the form,


or out of screen-reader's rendering