43 lines
2.3 KiB
Markdown
43 lines
2.3 KiB
Markdown
# Moshing Mammut
|
|
|
|
The fine folks on the [metalhead.club Mastodon Server](https://metalhead.club) occasionally share like to share
|
|
what they're currently listening to.
|
|
Having a quick overview over what is being posted can be a great way to discover new music!
|
|
|
|
# Technical Notes
|
|
|
|
This is fairly simple from a technical point of view! metalhead.club's local timeline is being watched using the
|
|
Mastodon Streaming API over a Websocket. Every time a new post arrives, it is checked if it contains any music by
|
|
checking included hashtags and URLs. A list of tags and URLs can be found in [the configuration](.env.EXAMPLE).
|
|
Additionally, lins to YouTube are queried, if they are music or other videos using the YouTube API.
|
|
|
|
If a post passes this check it is saved to a SQLite database.
|
|
|
|
The UI is built using [SvelteKit](https://kit.svelte.dev). The initial page is rendered on the server, and works even
|
|
without Javascript. If Javascript is enabled, new posts are fetched every 10 seconds, but there are plans to switch
|
|
to Websockets instead. See #10.
|
|
|
|
# The ~~Mastodon~~ Elephant in the Room
|
|
|
|
> So, are you just going to save other peoples posts into your own database?
|
|
|
|
I'm afraid so, and I'm not particularly happy about this. I've thought about how to do it without and it doesn't look
|
|
good.
|
|
|
|
My initial plan was to search for posts and work with the search results, however
|
|
Mastodon doesn't offer full text search, so this would be limited to work with hashtags.
|
|
I can see that there are plenty of posts using only descriptions and links without a corresponding hashtag that would
|
|
be missed. This isn't a great solution.
|
|
|
|
Another idea was to store only URLs of posts and resolve the content and account information live.
|
|
This would be better, but I'm *still* storing post information while also slowing the app down and introduce more code
|
|
complexity. I'm willing to make this change if people prefer this though.
|
|
|
|
Additionally, I ended up adding a few things which turned out to be not needed:
|
|
The `tags` table (tags are included in the post's content and I don't do anything separately with tags) and
|
|
`accounts.username` and `accounts.avatar_static`. I will keep these in until the initial wave of feedback arrives, and
|
|
remove it if no new features required them.
|
|
|
|
I'll gladly accept any help in coming up with a good solution which doesn't need to store anything at all!
|
|
|