<cwebber>
basically the idea of Mandy is that ActivityPub is just another membrane
<cwebber>
the same way ocapn/captp is a membrane
<cwebber>
it just accepts a specific kind of / limimted set of methods
<isd>
Yeah, the only bit that's tircky to me is how to identify caps in activitypub messages -- I think to do it correctly you basically need to have the membrane know about every activitypub data type that could contain actor references, so it's able to turn those into caps & back reliably
<isd>
Which is doable, but I wish I saw a simpler way
<ocdtrekkie>
I think I am going to publish a Sandstorm app here that is a single <50 line code file. \o/ Should tell you how stupid it is.
<ocdtrekkie>
@zenhack:matrix.org: I bet `<meta name = "color-scheme" content="light dark">` would work for both YATA and Prioritize pretty much outright. I think your weekly view tweaks might get broken applying it to Sandcal though.
<ocdtrekkie>
Oh, I guess these have stylesheets now, lol.
<blowfist>
ocdtrekkie: I've tried your Tube app and I can't seem to manage to upload any video to it
<ocdtrekkie>
blowfist: Are they really large videos, by chance?
<blowfist>
ocdtrekkie: uploading works but the processing ends with : 504 Gateway Timeout nginx
<blowfist>
no, very small, about 20MB
<blowfist>
I tried a 50MB and a 20MB video
<blowfist>
and also, uploading doesn't seem to work on android
<blowfist>
but then it doesn't work with davros either
<ocdtrekkie>
I haven't ever tested Tube on mobile. (And I should specify, fwiw, I am not the author of Tube, just the packager.)
<blowfist>
yes I noticed :)
<blowfist>
so you think those are app specific issues rather than sandstorm app specific issues?
<ocdtrekkie>
It uses ffmpeg for the processing, which generally should work, but I have noticed it can be slow, and it's a very hardware-dependent process. But I know Dan had issues with a video as well that had kinda weird traits.
<blowfist>
did you have to convert any of the file upload code to make it sandstorm friendly?
<ocdtrekkie>
I don't think we do much that should impact how the app works, but uploading content into Sandstorm has sometimes been challenging, so it is hard to be sure.
<ocdtrekkie>
Not at all.
<ocdtrekkie>
It does have a timeout in the config, I probably should bump out both the size and timeout limits on Sandstorm a bit more perhaps, but they're all set to Tube's defaults right now.
<blowfist>
well the files seem to upload just fine, (I can see the app's total size grow every time I try). It's weird that the processing part gets an nginx error though
<blowfist>
ocdtrekkie: there may be video formats that would not require a processing maybe?
<blowfist>
they mention mp4 H.265 AAC
<ocdtrekkie>
I think it always transcodes, but yeah that was something I noted as an annoying choice if I'm already uploading video browsers play well.
<blowfist>
the transcoder timeout is set to 300 seconds... I'm pretty sure it failed way before 5 minutes
<blowfist>
yeah I just timed it, it fails after just a minute
<ocdtrekkie>
And nothing useful in the grain log right? (Not that I think we do anything useful to pipe ffmpeg output there...)
<ocdtrekkie>
Maybe the grain is shutting down?
<isd>
Yeah, if it's happening a full minute after the upload completes, that's my guess.
<blowfist>
hmm but my nginx log shows the error
<isd>
I guess we have a concrete reason to put those keepalives back in now...
<blowfist>
the grain's log is hard for me to process :)
<ocdtrekkie>
Grain shutdown makes sense, I think we originally had a design concept that if you had the browser open the grain shouldn't shut down. But in practice it's a minute after last network traffic.
<blowfist>
2022/11/14 07:30:58 [error] 2446#0: *1591773 upstream timed out (110: Connection timed out) while reading response header from upstream, client:
<isd>
Hm, does tube not actually respond until the entire video is transcoded? Probably it should be responding with 204 no content and then backgrounding the transcoding...
<isd>
(also, alternatively, tube could acquire a wake lock, which could allow it to finish transcoding even if the user closes the grain immediately after finishing the upload, which I could see someone wanting to do).
<ocdtrekkie>
James tends to not have mandatory JavaScript where he can help it so it wouldn't surprise me if there's absolutely no traffic until transcoding is done.
<blowfist>
ah it seems the grain's debug log shows panic errors
<isd>
Care to share them?
<blowfist>
do you have a paste suggestion?
<blowfist>
paste service*
<isd>
Spin up a TextEditor grain or the like?
<isd>
(I forget not everyone's on matrix, which deals with large messages just fine...)
<blowfist>
I can't paste anything from firefox to a terminal in wayland right now and I can't seem to be able to send a message to my libera user from matrix so I messaged you with the link isd
<isd>
I do not seem to have gotten a message from you.
<blowfist>
ocdtrekkie: you may want to have that debug log output too
<isd>
Probably that should get reported upstream
<blowfist>
yeah, it's most likely upstream issues
<isd>
and I should go to bed. later.
<blowfist>
ttyl
<ocdtrekkie>
I also suspect the wakelock strategy is probably the right one for apps like Tube which may need extended background processing time, though I don't think I could add that myself. (Would we have to fork Tube to avoid drawing capnproto into the build for all users?)
<ocdtrekkie>
`error parsing template import: template: import:2:15: executing "base" at <.Playing>: can't evaluate field Playing in type *struct {}` etc. is an already reported issue upstream.
<blowfist>
I just checked the code and it seems to encode to h264 after all
<blowfist>
(and that makes a lot more sense than h265 which is 4K resolution AFAIK)
<blowfist>
ocdtrekkie: would be nice to have gitea on sandstorm as well btw :)
<ocdtrekkie>
Yeah, our GitLab and Gogs ports are a bit old, and I think it'd be good to have an updated more full-featured code hosting option on Sandstorm soon-ish. IIRC Gitea is the shinier Gogs, but maybe some of the same packaging design will hold up, I don't know.
<ocdtrekkie>
I like to use GitWeb as kinda a selfhosted backup for my GitHub projects, but it's nowhere near enough to run an actual code project out of.
<blowfist>
I may be wrong, but I believe the current gogs app doesn't support setting permissions at all, so sharing it means letting anyone do whatever they want with it
<ocdtrekkie>
Yeah, that looks like it is likely the case from the pkgdef.
jonesv has joined #sandstorm
garrison has quit [Quit: Ping timeout (120 seconds)]
garrison has joined #sandstorm
zarvox has quit [Ping timeout: 260 seconds]
mnutt has quit [Remote host closed the connection]
mnutt has joined #sandstorm
zarvox has joined #sandstorm
<blowfist>
I've been pondering the question of if it would be interesting/useful to have some sort of forum app into sandstorm. Something that could be used in conjunction with a blog or website to gather the feedback of people, any ideas?
<blowfist>
s/into/for
<isd>
Might be interesting to know how hard it would be to port discourse
<blowfist>
isd: how would you foresee the user management for that case? I wouldn't want to have to create a normal sandstorm account for each user that would use the forum, just so they can have their username
<isd>
Ideally discourse would provide an auth plugin framework, and we'd write one to integrate it with sandstorm
<isd>
The mediawiki & hedgedoc packages I maintain do similarly.
<isd>
I haven't looked at their internals at all.
<isd>
Not sure "creating a normal sandstorm account for each user" entails -- ideally folks would just log in and everything would work?
<blowfist>
If, from the sandstorm part, all it took was the creation of a visitor account, then that would be fine.
<ocdtrekkie>
NodeBB exists, though it's an ancient package
<blowfist>
especially since I think anyone can create such an account, even uninvited?
<ocdtrekkie>
Correct
<ocdtrekkie>
Anyone can sign into (almost) any Sandstorm server with their own identity.
<ocdtrekkie>
But it doesn't confer any right to do anything on that server in itself.
<blowfist>
maybe something simpler than a forum would be better too, just a place to post comments/feedbacks, maybe without the ability to edit messages
<blowfist>
each grain would be a specific topic/usage
<blowfist>
but then I guess that sounds a lot similar to a chatting interface, so I guess something like rocket chat or Simple Chat would fill the bill
<ocdtrekkie>
Yeah some of our chat/forum apps we have are very old but depending on your needs they may be serviceable.
<ocdtrekkie>
NodeBB seems fine. If you don't need mobile app support, Rocket.Chat is still solid.