We dug this out of the vegetable bed yesterday.
We didn't even plant garlic there this year.
Inane Remarks
Basil
@basil@trivial.observer
Basil's Blog / Digital Garden.
Posts and replies will appear here.
A victim of a series of accidents, as are we all.
Expect sarcasm, dogs, puns, sport, beer, cycling, tech, pubs. Sometimes several of these at once.
so it goes.
Northumbria
Fedizen since Jul, 2008
Here since May, 2023
Blog post from Saturday, have started one of the books, can almost guarantee that I won't finish it
https://trivial.observer/blog/2023/07/20230715/
New post. I've split my blog up to have more purposeful posts separated from rambling nonsense. So here's some rambling nonsense.
https://trivial.observer/blog/2023/07/20230717/
Filled a small paddling pool to try and cool the dog down this morning. She quickly drank as much of the water as she could manage, spent the following hour puking most of it back up, and now has a near constant stream of piss coming out of her.
Fediverse followers, note there will still be a fair bit of testing spam coming out of this account while I work out the kinks of my Gotosocial<==>Hugo nonsense.
Girl, 8, dies in Land Rover crash
https://www.standard.co.uk/news/london/wimbledon-merton-police-car-camp-road-school-b1092601.html
This death, like the rest, is a baked-in consequence of our choices.
From road laws and enforcement, through infrastructure design, right down into the setup of our communities, and the function of modern living being designed around the necessity of flinging multi-tonne juggernauts around the place just to go about your day in any normal fashion.
And collectively, we've decided it's fine, for example, to have hundreds of Panzer tanks driving past schools every day.
Managing Hugo content in a submodule
https://www.eliostruyf.com/managing-hugo-website-content-asset-submodule/
Suddenly I had this thought today when pondering using different writing tools. Looks like plenty of people do it so might give it a go. Keep the writing completely separate from the website. Decoupling all the things.
Webfinger (and similar systems) can store meta data about an actor, but we seem to only use webfinger for endpoint / uri discovery.
My understanding is that we ask a social media server (e.g. a mastodon instance) for the ActivityPub outbox for "@user@server.com" and maybe some other info.
But I'm sure it can store anything we like, so why not social graph stuff? I'm mainly thinking about connections and interests.
E.g. mine would list all the ActivityPub accounts I follow and then a list of topics I'm interested in. Then everyone in that list who I follow would have a file that did the same.
Why then, can I not query these files for all ActivityPub accounts, up to 4 degrees of separation away, that are interested in Cycling or Football?
I feel like the fediverse in missing a trick. It's a halfway house between an algorithm on-boarding you and the cack-handed manual discovery that is being relied on currently.
But this is such an obvious thought, I must be missing something.
Images are working and so are @basil mentions.
Think I'll call that a night before I break something.
My days are spent on handover meetings and writing half finished thoughts and observations in a wiki. It's a hoot.
Perhaps the compromise is to copy the files between the folders on the server.
And upload them to the repository.
But omit the images from the rsync to the server.
Removes one leg of the round trip, and keeps the repository source completely intact.
When dealing with images I upload here, I need to send the images from Gotosocial to my Hugo blog.
Do I maintain the purity of the Hugo GitHub repo even though it's a wildly inefficient round trip? It's basically moving an image file from /gotosocial/storage to /var/www/images but via GitHub.com
Do I just make the Gotosocial code copy the image to the folder I need it, meaning the Hugo site is not fully self-contained in GitHub. I.e. I can't just clone the repo and run Hugo to have a fully functional and complete site.
The Dev team at CurrentEmployer Plc consists of 5 Devs of varying abilities. 4 of us have been at the company about 12 months and 1 guy about 6 years.
This person is leaving and so obviously there's a tremendous amount of knowledge transfer and documentation that needs doing.
Déjà vu all over again. Single points of failure and institutional memory.
Oh, and of course we've been told that managing a smooth handover is the absolute overriding priority* for the team.
*but existing priorities are also important and should not suffer.
And, in theory, it should handle fediverse replies as well.
I would like to have it infer when something is a response to an internet article, e.g. Detect if the first line of a post is a URL, in which case assume the post is "in response to".
What's also not done yet are deletes and attachments.
Deletes should be simple... Media attachments... Not so much.
So, if it's all working...
This is a post written in tusky, that Gotosocial will create in its own database.
It will also send the post info to my GitPubHub endpoint, which will build up the markdown for the note and send it off to GitHub.
Where a job will be triggered to build and deploy the Hugo site with the new note.
Hate tutorials that aren't date stamped. Is this tutorial 20 years old using deprecated functionality? Guess I have to read the tutorial, learn the method and terminology then research it to find out if I just wasted an hour.
Couldn't get indiekit working as a micropub endpoint. I discovered a bug and after working around it, found more issues...
So now I'm rolling my own GitHub publishing endpoint like an idiot.
This could have legs... But it means I have to figure out how to configure indiekit properly... Which I've been putting off.
It may also introduce scaling concerns if I reduce note published friction this much.
Once again the question is where's the boundary between
article/note/post
e.g. why is this reply a post and not a note?
In the proposed system all posts would be notes. Even the briefest of replies.
Needs more pondering.
Hmmm. Given a source of friction is posting from an app that isn’t that great maybe I can invert the publishing pipe and maintain the same result.
instead of:
Micropub app -> indiekit -> Git -> Website -> Gotosocial
Do:
Tusky -> Gotosocial* -> indiekit -> Git -> Website
*Update the status creation code to hit the indiekit micropub endpoint. There will be a lag where the Gotosocial status exists with a URL that will 404 until the Hugo site has time to publish the new note.
I don’t have to worry about posting images either inside notes or in their own objects until I get the indiekit micropub configured correctly.
Although this part was lazy and quite unfair: "wasn’t complicated like NetNewsWire, it didn’t crash like Bloglines"