Remote media download just works (tm) too, very easy to get the remote homeserver base url properly with https://www.npmjs.com/package/@modular-matrix/autodiscover-client-configuration
and initial commit published!
https://git.pixie.town/f0x/synapse-media-proxy
:O I think I implemented the whole https://spec.matrix.org/unstable/server-server-api/#server-discovery Matrix server discovery flow!!! It's rather complex, with .well-knowns and SRV records and combinations of those.
Also nice that I could fork of the client-spec counterpart already made by someone else :) https://www.npmjs.com/package/@modular-matrix/autodiscover-client-configuration
submitted 2 things to TWIM https://matrix.org/blog/category/this-week-in-matrix for the first time in aaaages :3
soo good to just come across a library that does what you need to *perfectly*. I was messing about with regexes to parse Content-Disposition stuff, and with this library I can do both the parsing and formatting sooo much nicer (and it's used by express.js so it's Good(tm))
https://www.npmjs.com/package/content-disposition
think I'll set up a test synapse-media-proxy soon(tm) but I'd accompany it with a testing synapse instance too, think NixOS should make it real easy to get that part up and running quick, and then I can get some real-world speedtests by just throwing test media links around :P
Monday though i suppose... i should really learn at least a bit for that fuckin midterm first
big refactor in preparation of thumbnailing support https://git.pixie.town/f0x/synapse-media-proxy/commit/7f2cb50b85ed30fbf6939087559ee5fab479e979
uhh, uhh I think I just fully implemented the thumbnailing in synapse-media-proxy??!?
https://git.pixie.town/f0x/synapse-media-proxy/commit/68829b5c115cd5ddbec4e528051360ba103b5111
And now you just get a proper error when trying to thumbnail an unsupported file (like a .txt lol), instead of crashing the server with an uncaught error :")
https://git.pixie.town/f0x/synapse-media-proxy/commit/8b867a48308ddd0437db37854698dc241a87b457
aaaaa I got an absolute superthought under the shower on how to speed up concurrent access of non-cached media but I have a fucking meeting first before I can implement it aaaaa
ok subscribing to streams when they come available works, subscribing to an already existing stream doesn't because some of the data will already be read-out from it (and thus removed).
And seems having multiple subscribers to the same stream isn't ideal either as varying network speeds/stream consumption would give a similar issue, hmmm
I guess this is the second yakshaving time where I really dive deep into the internals of a Node subsystem (last time it was the module system, resulting in https://www.npmjs.com/package/@require-transpile/core)
I did the proper thing and looked at existing implementations! and there's a module to split a stream to multiple consumers (nice), but nothing that keeps a buffer to backfill late-joiners. This will integrate *perfectly* with my current architecture because I'm already saving the whole stream into a buffer anyways (for later cache serves)
so:
- first request comes in, upstream starts streaming to the first client
- second client requests that file while it's still streaming, it gets a new stream with the buffer up till now + then the new data
- upstream request finishes
- new clients get the whole cached buffer
good news: I did not really know what I was doing!
but now it is done, another biiiiig refactor commit with the new streams architecture https://git.pixie.town/f0x/synapse-media-proxy/commit/091e9dc346a23abdab2a4a660857fee30530c4df
and another published package: https://www.npmjs.com/package/stream-copier
synapse-media-proxy serving files well :3
backed by an actual Synapse here, running on my NixOS new homeserver
plant:
https://media.pixie.town/_matrix/media/r0/download/media.pixie.town/w3sOEEfriKfTTsn4Ad4NyggC
ah yes and this classic video https://media.pixie.town/_matrix/media/r0/download/media.pixie.town/pHAuiyxqRyQE80iciHfhDwMx
lol you can definitely see when I started testing things (aura is the <remote> component, cosmos the <local> server at home)
https://stats.pixie.town/d/stats/node-stats?viewPanel=8&orgId=1&refresh=10s&var-job=aura&var-job=cosmos
submitted another TWIM with the synapse-media-proxy updates, icymi:
- thumbnailing!
- metrics!
- fancy dashboard in progress! https://stats.pixie.town/d/rPBvoh6Gk/synapse-media-proxy?orgId=1&from=now-30m&to=now
- teapots! https://media.pixie.town/_matrix/media/r0/download/im_a/teapot
the stats dashboard is interesting, there's a lot of people clicking the media link (or browsers prefetching it?) from the This Week In Matrix article i presume
https://stats.pixie.town/d/rPBvoh6Gk/synapse-media-proxy?orgId=1&from=now-24h&to=now&refresh=1m
@f0x don’t forget to write the idea down…
@erikk done :)
@f0x fast!
@f0x Your not sending caching headers or is that intentional?
@erikk haven't added those yet, no dunno how useful those even are when remote users (majority) will fetch it through their own media repo which caches it indefinitely anyways
@erikk synapse sends cache-control public,max-age=86400,s-maxage=86400 (1 day) I guess I could just copy that
@f0x it downloads basically instantly.... are you a wizard?
@dumpsterqueer just having it served directly from the cheap hetzner box has soo much better internet than my home :D
and it's even cached in RAM there :)
@f0x aha :P that'll do it!
@f0x I don't know what any of this means but it looks cool
@f0x oh wow, that is a big fucking difference!
currently an upstream request stream gets piped to the first requestor, and to a buffer for the later cache, but instead I should store a reference to the stream immediately so it can be piped to new requestor immediately as well, while it's still in progress!