@freebliss@post.lurk.org
@freebliss@post.lurk.org avatar

freebliss

@freebliss@post.lurk.org

Code, media, and systems with a focus on ethics, simplicity and sustainability. Occasional libre graphics steward in vienna. Illustration scholar. Nightclub pianist without nightclub. he/him.

This profile is from a federated server and may be incomplete. Browse more on the original instance.

freebliss, to random
@freebliss@post.lurk.org avatar

I just wanted to help a friend degooglify their shared rehearsal room calendar, but it ended up with me getting nerd-sniped into building a smol, nice calendar for small collectives/friend circles. (/▽＼) It's a single php file you can drop in any webhost, then it walks you through first time setup and then it's up and running. It persists all data to an adjacent php file, so you can simply backup/transfer the calendar by moving the files between computers. We'll do a test-run with the shared rehearsal room, then I'll release it (copyleft). It's also mobile-friendly, has dark/light mode, only 5 lines of (optional) javascript :D, and I'm doing my best to get accessibility right from the get-go. I'm kinda excited, and highly amused what an easy nerd-sniping target I am. Yay! :D

A simple settings page for a calendar, allowing editing of title, weeks shown, start of week, editing users, adding users. Each user needs a key, name and permissions setting.

freebliss,
@freebliss@post.lurk.org avatar

@gullfot thank you for the kind feedback! ( ◡‿◡ *)

freebliss,
@freebliss@post.lurk.org avatar

@aaaaa awesome, i'll ping you! i estimate a mid-january release, let's see how the wrap-up and live test goes. ;)

freebliss, to random
@freebliss@post.lurk.org avatar

In collaboration with @lislegaard (thanks for the help!) we've identified a rare unicode filename encoding gotcha with #faircamp ftp deployment. As there was no thematically fitting manual page to document this gotcha, I wrote an entire manual page outlining the principal process and requirements for going online with a faircamp site (as always, happy about feedback on the documentation, I tend to miss obvious things). Enjoy. :)

https://simonrepp.com/faircamp/manual/going-online.html

freebliss, to random
@freebliss@post.lurk.org avatar

A small but quite essential new #faircamp release 0.11.0 is out: Markdown and html in catalog and release texts is now rendered to plaintext for the RSS feed (making feeds actually valid™), urls to download files are now encoded to resolve issues with unsafe characters, sites can now be generated in norwegian bokmål (many thanks to @harald), and the favicon can be entirely disabled now for extra smolness.

Thanks everyone involved in the release issues for helping out <3, and a shout-out to @themissingcow for handling the macOS brew release(s)!

Sidenotes: I presented faircamp at the @servus d*sign week in linz/austria last week, had some great conversations with peers on possible futures of libre and self-empowered music publishing recently (and more coming up), and I may have some exciting general faircamp news to share soon, but alas still too early to tell, even I don't know. (¬‿¬ ) Stay tuned.

freebliss, to random
@freebliss@post.lurk.org avatar

@themissingcow @fgaz I just tagged a new faircamp release (0.11.0) :) No stress at all, but if you get around to it sometime, would be fantastic if you could update the brew and nixos package releases to this latest version. Thanks for your kind support! ٩(◕‿◕｡)۶

freebliss,
@freebliss@post.lurk.org avatar

@fgaz Excellent! No worries at all, greatly appreciate your support, thanks a lot \o/

freebliss, to random
@freebliss@post.lurk.org avatar

There's going to be a small new #faircamp release later this week (with some great help from team norway \o/), in the meantime tonight there's two fresh additions to the manual:

  1. All the way at the bottom of https://simonrepp.com/faircamp/manual/catalog.html there's now a section on how to verify a faircamp site link on your mastodon (or similar) profile. Credit for this goes to @canterberry (thanks a lot!)

  2. The faircamp manual now supports dark mode and received some detail color/readability tweaks as well: https://simonrepp.com/faircamp/manual (dark mode uses system preference only so far, so you'll only see it depending on system configuration).

Speaking of darkness - black metal too has entered the faircamp universe in the form of @proteque's https://gorr.no/. I'm delighted. (*_ _)人

knova, to random

@freebliss Simon - finally got my site working on Faircamp. Thanks for the tool. https://knova.net/

1 question - any plans for volume control? Seems to be the biggest gripe from people I've sent my revised website to.

freebliss,
@freebliss@post.lurk.org avatar

@knova Awesome and thanks for letting me know - added it to the list of faircamp sites!

Volume control has come up once so far in the issue tracker, it's something I personally, in the interest of visual and functional simplicity, would like to leave out if possible, also somewhat informed by the observation that bandcamp seems to get by without it just fine (but maybe everyone but me is furious that it's missing, idk haha). In either case it's super interesting to hear that (even multiple) people have voiced this to you - thanks for the feedback! If you happen to know, I'd be interested to know where this comes from exactly. E.g. is it more the direct difference between your previous website, or was the feedback coming from habitual soundcloud users, or something else I'm not thinking about? Happy to hear if you got any details on it, but no stress either, this is already great feedback by itself. Thanks again!

freebliss, to random
@freebliss@post.lurk.org avatar

My domain provider (easyname) increased my yearly domain fee for .com by 60%. Asking for a justification, support replied that they're just passing on price increases from their domain registry. Is this credible? 60% increase for .com registrations at the B2B level seems like a big deal, given its the most widely used domain out there?

freebliss,
@freebliss@post.lurk.org avatar

@datacop ah good to hear that i'm not the only one a bit fazed about this :) I'm absolutely clueless in terms of registrars out there, so thanks for mentioning some alternatives!

freebliss, to random
@freebliss@post.lurk.org avatar

@rra a while ago you mentioned the lean infrastructure running your cargo bike collective - a calendar and a combination lock iirc (?) I'm curious what calendar you're using? (looking for a minimalistic calendar solution for something similar right now) thanks for a(ny) potential pointer(s)! :)

freebliss,
@freebliss@post.lurk.org avatar

@rra ah great to know! thank you :)

freebliss,
@freebliss@post.lurk.org avatar

@rra @praxeology good to know thanks! :) to be a bit more precise, our usecase is for a shared rehearsal space, so the key/lock situation is in order, but we are on the lookout for a really simple but reliable calendar thing that is not provided "as a service" by the usual suspects ;) I've actually proposed a pad right away but wasn't sure if it's practicable as a calendar replacement, but given your feedback it seems it is! :)

rotfarm, to random

In my battle with having my release and my only track be the same name
In the .eno file. It must be stated that the permalink does not accept capitalizations, or underscores in the differentiation of Release Name and Track Name.
my permalink : garden-ep
title : Garden EP

This probably seems like it makes sense for anyone not a coder, but it in my travels as a total noob at this. This must be stated in the instructions for people to follow if you want people to do this.

Minute differences like these are what create gaping chasms in learning, or even the beginning of caring about adopting your wonderful contributions to DIY tech, so plelase don't forget how much we don't know. It must mean nothing to you, but this is enough to turn tail and never touch anything foss ever again.

#faircamp #documentation #TechForRegularPeople

freebliss,
@freebliss@post.lurk.org avatar

@rotfarm Thank you for bringing these concrete points up and taking the time to share it, this is exactly the way we/I can improve these things, and I appreciate it greatly. For me, for any developer probably, writing documentation is essentially writing into the void - it's very hard for me to anticipate what people will stumble over, what they need more, what they need less. Sometimes I will miss obvious things (like the allowed characters in a permalink) simply because I get lost in all the 1000 things that need to be done in the project. If I get pointed to them, I'll fix them. Please feel free to mention (@) me for such issues, I'm trying to follow the #faircamp hashtag, but I will miss some, especially as there are more and more posts coming in.

I added this page, which addresses the general topic you point out (and very rightly so), and has a longer explanation on permalinks in faircamp: https://simonrepp.com/faircamp/manual/concepts-explained.html

There's still a long way to go to improve the documentation, and I'm aware that there are for instance still big missing pieces in relation to at all explaining the hosting aspects, but I'm commited to put in the time and work on these things, piece by piece as I get to it and am pointed to them, so thanks again for doing that!

themissingcow, to random

@freebliss should be in brew for macOS now. Now the initial PR is merged I’ll get it updated to 0.10… https://formulae.brew.sh/formula/faircamp

freebliss,
@freebliss@post.lurk.org avatar

@kel faircamp sometimes builds intermediate assets. E.g. to provide a zip of .wav files it first transcodes every track to .wav to the cache directory (these are intermediate assets), then it writes all these files into a .zip directory in the cache directory (this is a deliverable asset). Only the .zip gets copied (technically actually hardlinked) to the build, the intermediate .wav files remain in the cache directory. If you build again after >24hours and this consecutive build does not use the intermediate assets anymore (would be the case if you e.g. enabled single track downloads then) faircamp will delete the intermediate assets from the cache to restore storage space. (Note: this describes the default caching strategy, can be configured). So that's what you're seeing. As long as it does not start removing assets that are deliverables, everything should be fine. :)

freebliss, to random
@freebliss@post.lurk.org avatar

@cblgh awesome reply on the rss question (thanks so much (⌒‿⌒)) processing it and scheming my next move currently haha.

Another thing though! Just saw this: "(...) one possible solution for open source precarity, Rad Reader will be 100% open sourced on reaching 350 purchases."

I think this is a very promising model in general, and I'm super excited to see you putting this into practice! First because I've been rolling the same thought in my head for a long while now, and second because this summer I've actually pitched that kind of development model to a university here in vienna. They would have even kinda gone for it, but ironically we/I received a grant for another project (and now faircamp exploded a bit) so I couldn't really go through with my own pitch due to resources. But yeah, all the better to see it out in the wild now, and you going about it in a very practical manner. I was obsessing quite a bit over how to legally bind myself to having to follow up with my promise to open source $project after amount x has been reached, but maybe it's better to just build smol stuff so the stakes don't require all that legal bloat. x)

freebliss, to random
@freebliss@post.lurk.org avatar

@yonder just as a headsup because I know you're the one looking at this the hardest, and possibly building on top of it already right now: I've done some more research on what I wrote in https://codeberg.org/simonrepp/faircamp/issues/47#issuecomment-1328935, and additionally I've put things together once again in probably the most clearest wording so far in https://post.lurk.org/@freebliss/111387468223149412 (have a look at that last one especially). All of this makes me seriously reconsider the addition of the release date through pubDate - it just seems really problematic - so maybe consider pausing any effort to immediately use it in the aggregator (if already on it), until this is properly thought out. Apologies for the back and forth, I should've taken a bit more time to really think that addition through. :/

freebliss, to RSS
@freebliss@post.lurk.org avatar

If there's any #rss veterans or former (or current) feed reader developers or spec nerds reading this, I'd be super interested in your take on a more subtle point around the item pubDate element, I've elaborated a thought here: https://codeberg.org/simonrepp/faircamp/issues/47#issuecomment-1328935

freebliss,
@freebliss@post.lurk.org avatar

@kel lastBuildDate (on channel) is entirely unproblematic - that's just the timestamp when you run faircamp to generate your site. As for pubDate (on item), there might be no problem with it, but in the worst case it could mean that if you put up releases today that lie in the past, someone's feedreader might display them way back in the past (in terms of ordering in your chronological feed) and no one would see them then. It entirely depends how a feed reader handles this though, I can't really say.

freebliss,
@freebliss@post.lurk.org avatar

@kel cool thanks - will give this a deeper read soon!

freebliss,
@freebliss@post.lurk.org avatar

@kel hm I'm not sure but I think my explanation was not clear, let me try it like this:

  1. You subscribe to the feed of your favorite vintage music label, today in 2023 2) Three days after you subscribed, that label puts three previously missing releases, each of them released in 1970, up on their site. 3) Your feed reader receives the update, but given that the pubDate on these three releases says 1970, considers them very old news, hence you never ever see them - they are silently inserted somewhere in the remote past of your reader timeline where you'll never ever scroll to.

This scenario is what I'm pondering, and I think regardless of whether one classifies this behavior as technically correct or not, it would render the rss feed useless for any site operator that publishes music of the past exclusively. Hope that makes sense.

freebliss,
@freebliss@post.lurk.org avatar

@kel indeed :)

torstentorsten, to random German
@torstentorsten@social.tchncs.de avatar

#Bandcamp ist an den Höchstbietenden verkauft worden 💰 (wieder mal).

Zum Glück gibt es jetzt aber #Faircamp. Das ist eine Alternative zu Bandcamp, die relativ leicht auf der eigenen Webseite installiert werden kann.

Und genau das habe ich auch gerade getan: https://torstentorsten.de/faircamp/

Danke @freebliss für die tolle Software und @meljoann für die Erklärung!

Falls jemensch sowas auch haben möchte und Hilfe beim Einrichten braucht, sag gern Bescheid. =)

freebliss,
@freebliss@post.lurk.org avatar

@torstentorsten @Herr_Irrtum Ich hatte wie ich mit der Entwicklung von faircamp begonnen habe ehrlich gesagt überhaupt nicht damit gerechnet dass so ein Diskurs rund um Indexierung und Auffindbarkeit (v.a. so nah dran an faircamp selbst) entstehen würde, aber ich verstehs natürlich. Also in dem Sinn denke ich jetzt viel über diese Fragen nach, und hoffe dass sich nach ausgiebiger Recherche, Vernetzung und Austausch mit denen die das Feld schon länger beforschen allmählich ein oder mehrere Ansätze herauskristallisieren ob und wie dieser Datenaustausch von faircamp aus mitrealisiert werden kann. In ein paar Wochen wird der Ausblick hoffentlich klarer sein ... :)

yonder, to random
@yonder@spacey.space avatar

@freebliss @meljoann @keefmarshall

Prototype aggregator:

https://ten-thousand-sounds.com

Had a go at a Faircamp style aggregator - made with a python script that downloads the feed.rss file from sites that have it, then uses faircamp to generate a label mode Faircamp site from them. All links from the directory page are replaced so they go to the respective artist release page or home page. The result is one page that has links out to everyone's own pages and has the faircamp look.

freebliss,
@freebliss@post.lurk.org avatar

@defaultmediatransmitter gotcha. I mean on the tough-but-nicely-isolated-issue end there is one issue in a crate that faircamp depends upon - https://codeberg.org/simonrepp/faircamp/issues/44#issuecomment-1320271 - but I'm hesitant to propose this as a learning ground. Rust can be incredibly nerve-wrecking to get into even for (in other languages) simple-ish problems, and this issue is something I'm not even sure I want to get into. Neither did the developer themself so far, that's never a good sign. :) Maybe even just looking a bit at it is educative though (regardless of whether one wants to then actually fix it). I'll try to report other stuff as it comes up!

freebliss,
@freebliss@post.lurk.org avatar

@defaultmediatransmitter make that "courageous"! :)

  • All
  • Subscribed
  • Moderated
  • Favorites
  • •
  • JUstTest
  • ngwrru68w68
  • everett
  • InstantRegret
  • magazineikmin
  • thenastyranch
  • rosin
  • Durango
  • khanakhh
  • Youngstown
  • slotface
  • ethstaker
  • kavyap
  • DreamBathrooms
  • provamag3
  • osvaldo12
  • normalnudes
  • modclub
  • GTA5RPClips
  • tacticalgear
  • mdbf
  • tester
  • cisconetworking
  • anitta
  • Leos
  • cubers
  • megavids
  • lostlight
  • All magazines
    •