I've been posting high-quality audio of my #looptober tracks at https://music.mysteryhouse.studio/library/albums/2/ and funkwhale is impressive and ambitious but it also feels like wordpress, where you go into it thinking "Oh cool I'll just spin up a little blog" and then you realize that it has about 200 more features than you want and they're all enabled by default"
Like, I just want an account to share some audio tracks, maybe group them into albums, include a player UI if you're browsing the site directly. More like federated bandcamp than federated spotify
I’ve picked up this thread again and while tinkering with schema have immediately run into the “user” vs “artist” conundrum and am already trying to over-engineer.
It’s the result of having been burned multiple times over the years by doing the fastest/barest minimum to get a thing working and then having to do all kinds of gymnastics to work around unanticipated edge cases
…in the context of a personal project I know from experience that if I reach a “time to burn it down and start over” inflection point on a personal project I usually just abandon it.
Anyway, re: modeling, while it’s technically true that an album or track can be associated with more than one artist, and that a user could also be associated with more than one artist, I feel like most hypothetical users of an open source federated music publishing thing are going to be solo artists (or, they’re going to be one person who handles online stuff for a band)
The “one account, multiple profiles” thing was what I immediately disliked about funkwhale, so I’m not going there. As a futureproofing concession to myself I’ll make a separate ‘Artist’ model but keep User::Artist, Artist::Track, Artist::Album, etc strictly 1:1 for now
mehhhh I guess I should take the time to rule out TypeORM
Anyway, it occurs to me that if I’m using UUID primary keys then I shouldn’t need to worry about data types in a hypothetical “I just want m2m tagging without umpty join tables” scenario, at least from one side of the join. I could still kluge a ‘type’ field into the join table to be able to query by tag + type if I needed to
Hey fediverse: Does there exist an audio equivalent of https://picsum.photos/ ? IE, hit a url or a web api and get a random audio file? I’m at the “need to populate the database with a bunch of fake data” stage and I know I *could* just use files I’ve got kicking around locally but real-world randomness is always better.
One of the hardest shifts for me to make as someone who learned how to build web stuff when most people were still on 56K dial-up connections is the modern "just indiscriminantly make a bunch of HTTP requests to load the various parts of a page, whatever 🤷" philosophy
Since I decided to implement my own generic foreign keys for things like tagging, it means I lose the ability to do prisma queries that automagically return collections of related objects, which means that I either need to write a bunch of extra code to achieve that server side, or just give in and make multiple requests (and, in turn, multiple db queries) to load that data sequentially on the client side. It's not a _ton_ of extra requests but it feels so... inelegant
...I also have a stubbornly hard time with the whole "better to load a page incrementally than for a user to suffer the grave indignity of having a page take more than a hundredth of a second to respond" thing
like, try surfing the internet on a noisy 56k AOL internet connection and *then* talk to me about page loading times
Oof, so if you make a (relational DB) query with prisma and say "Include records from this relationship" it does so by doing a separate query
I think that's the default behavior in Django too but Django has options that let you explicitly specify that a table should be joined, or doing a 'select from [related table] where related_id in [ids from the main query]' instead of doing n+1 queries everywhere all the time
I mean I know this stuff is hard, especially when you're supporting multiple backends, but the response to tickets asking about joins seems to pretty much be "queries are cheap lol"
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!