<isd>
I'm more immediately grumping about this in the context of C++, so no closures, but for a systems languge Rust still does this right: you can mark fields private, and then you have stand-alone functions that at some point use a data literal. The way C++ does this is bonkers
<isd>
I also just hate the way C++ references work, and the fact that nothing can be assumed to be a simple assignment; everything is potentially calling a constructor and/or an overloaded operator.
<isd>
rvalue references make this even worse; assigning some sub part of an expression to an intermediate variable is potentially not semantics-preserving... AUGH
<isd>
I'm going to go for a walk, then sit down and fix the patch.
kawaiipunk has quit [Quit: Leaving this Club]
kawaiipunk has joined #sandstorm
xet7 has quit [Quit: Leaving]
xet7 has joined #sandstorm
<TimMc>
My spouse is looking for chat software we can host and was sad to discover that the Rocketchat in Sandstorm is so old. Is there any ongoing work to bring a newer Rocketchat in, or any other chat software?
<TimMc>
I'm also curious if there's anyone in the community who could be paid to do that work. (isd, I don't know how elastic your time and work schedule are, for instance!)
<isd>
I don't think anyone's working on it.
<isd>
Rocket.Chat used to maintain their sandstorm support in-tree.
<isd>
But dropped it around the time sandstorm went out of business
<isd>
tbh, I haven't taken much contract work lately, so it would probably come at the expense of /other/ sandstorm related work if I was doing it (though I guess hypothetically it would stave off needing to take on something for a bit longer)
<JacobWeisz[m]>
They used to even have it build and submitted by CI, I think.
<isd>
Though I'd be open to prioritizing it. But I'm also not sure I'm the optimal person to work on it; not really familiar with the codebase, and I know folks have bounced off of it in the past. It might be worth prodding the rocket.chat folks, both in terms of guaging their willingness to maintain support going forward, and to see if anyone is up for doing the initial fixing.
<isd>
I've had the idea for a while of packaging an xmpp server & web frontend, probably https://conversejs.org/, but there are so many things on my TODO list...
<JacobWeisz[m]>
There was a long open issue on readding the Sandstorm build to CI. But nobody over there took it up.
<isd>
If there's funding to offer, maybe that could changes things on their end?
frigginglorious has joined #sandstorm
<xet7>
TimMc: Have you tried SandChat ?
<JacobWeisz[m]>
It is kinda minimalist but tbh, I would rather develop Sandstorm-native apps than shoehorning in outside packages to some degree.
<JacobWeisz[m]>
Rocket.Chat's ability to share grains is nice though.
<xet7>
Both Wekan and RocketChat are made with Meteor. I do Meteor development with Wekan daily. I have made some customizations to RocketChat. So in theory, I would be able to do that RocketChat upgrade, although it would be a lot of work.
<xet7>
Although, I do have my Wekan paying customers breathing to my neck when something will be ready.
<xet7>
Some login parts of RocketChat have been ported to be part of Wekan, by some Wekan contributors.
<JacobWeisz[m]>
That's a project I'd pitch in for. I think Lauri could invoice OpenCollective for that work if he had a number that would meet the workload, I imagine?
<JacobWeisz[m]>
Assuming he had time to take it on at some point.
<xet7>
Problem with Sandstorm related work is currently, that nobody is currently funding it.
<JacobWeisz[m]>
A bunch of people fund Ian directly.
<xet7>
I do love the Sandstorm platform very much. Got the T-shirt, spent countless of hours keeping Wekan running, I do host many websites on my Sandstorm install, etc.
<xet7>
A couple of my customers have asked have I got anything currently broken things in Wekan Sandstorm version working yet.
<xet7>
And I also translated Sandstorm to Finnish.
<abliss>
sandstorm-first is great in theory, but we don't have the dev-hours to keep up in a feature race (and won't any time soon)
<xet7>
Well, if Python with PostgreSQL eats CPU, I don't know how Meteor with Node/MongoDB is any different
<xet7>
Or are all huge systems slow?
<abliss>
yeah, the deeper I looked at synapse itself the less I liked it. There's another backend called dendrite being built in Go, which implements the same api atop a seemingly more solid foundation
<isd>
I doubt postgres is the problem.
<abliss>
the matrix folks seem to have a pretty clean separation between the protocol/api and the client/server impls, which I appreciate.
<isd>
Node is a _lot_ faster than CPython.
<xet7>
Well, I tried Go some years ago, it did keep crashing on Windows server, so I kind of still have scars from Go. I also tried to get some Go-based kanban software running, and I failed.
<abliss>
(fwiw I've been using the matrix.org backend, which i believe runs synapse, and their android app (called Element, previously called Riot) as my only connection to IRC for almost a year now, and have been quite pleased with it)
<isd>
...but I doubt the actual problem is "python is slow" it's more likely there are just bugs.
<xet7>
Yes, they are bugs. For example Saltstack, that is made with Python, is very fast on huge scale.
<xet7>
Wekan is also slow, because it can fetch too much from MongoDB at once
<simpson>
(My rule of thumb is that Node is around 4x faster than CPython. It's impressive, but PyPy exists and readily spanks CPython, so it's very much about the ecosystem, not just the interpreter.)
<isd>
Most perf problems I've seen in the wild are big-O problems that wouldn't be solved by using a different toolchain.
<xet7>
Only very minimal optimization has been done
<abliss>
I wonder if anyone on RC or Matrix has addressed the question of whether they have fundamentally different goals, or whether they should consider combining forces
<simpson>
abliss: We *definitely* have different goals. I'm here from #erights/#monte explicitly to combine forces and make more CapTP implementations using Capn Proto RPC.
<xet7>
Well, I'm still thinking how to make CloudFlare Workers version of Wekan possible, without Meteor. CloudFlare did announce some new bigger storage type some time ago, I have not yet asked about getting access to it.
<isd>
xet7: I think you're probably talking about a total rewrite there.
<isd>
...I kinda wish we could get away from meteor in sandstorm itself, but I don't see a remotely plausible exit path.
<xet7>
Sure, of course I'm always talking about total rewrite, like I have for many years. Thinking about it is my hobby. It's just that paying customers would like to get new features and fixes to already exising Meteor-based Wekan, and not to some new vaporware.
<abliss>
(i asked for access on Day 1, to try to build a chat prototype, and have not yet been invited to the closed beta)
<xet7>
existing
<xet7>
Wekan bundle is currently about 60k files of HTML/CSS/JS/images etc, it's kind of too much for CloudFlare Workers, I presume.
<xet7>
And I have maintained Wekan for 4 years
<abliss>
(Also, just to put it out there for TimMc , I made a verrrry basic prototype of Matrix + Riot as an in-sandstorm chat app; it's not as well-adapted as RocketChat, but starts from a newer basis, so that path *might* be worth considering if you are looking to pay someone to work on a modern sandstorm chat app. you can try an spk at https://github.com/abliss/sandstorm-synapse/releases/tag/sandstorm-v0.0.0-rc2 if you want )
<xet7>
Oh, someone emailed me about appreciating all the hard work that I have done with Wekan. Sweet! That encourages me to continue.
<xet7>
They upgraded to 100 versions newer version of Wekan.
<isd>
Every now and then my laptop runs out of disk space and I realize I have tens of gigabytes of old dev builds of sandstorm lying around...
frigginglorious has quit [Ping timeout: 246 seconds]
frigginglorious has joined #sandstorm
<TimMc>
xet7: SandChat is too minimal, I'm afraid. Looking for something with multiple channels/rooms within the same UI.
frigginglorious1 has joined #sandstorm
<TimMc>
abliss: Interesting! I'll take a look.
frigginglorious has quit [Ping timeout: 260 seconds]
frigginglorious1 is now known as frigginglorious
<JacobWeisz[m]>
I mean, a someday future would be that your multiple channels or rooms are still separate Sandstorm grains but you can move between them seamlessly.
frigginglorious has quit [Read error: Connection reset by peer]
<JacobWeisz[m]>
Something like where opening a private chat with someone in a room launches a new private chat grain, shares it between you, and opens it.
frigginglorious has joined #sandstorm
<isd>
I think we need to seriously improve our story on organizing grains before that's really going to be a good solution. there are window-management questions. But yeah, it would be conceptually nice if your multi-channel chat was just a collections grain of single-channel chats.
<JacobWeisz[m]>
There's a few totally-shell-side features that would be nice. I'd like to both pin and archive grains, for instance.
<isd>
Those both sound like good features. Are there open issues for those?
<JacobWeisz[m]>
Like if a grain is in a collection, or if I'm mostly never using a grain again but keep documents I write around, I'd hide it.
<isd>
Yeah, I have enough grains on my server that without the search it'd be completely unusable.
<JacobWeisz[m]>
I am pretty sure there are for one or both. I'll check.
<isd>
Don't remember if I mentioned this, I started working on a per-grain settings page, which will give us a place to put stuff about scheduled tasks, held capabilities, and other per-grain stuff we don't have UI for.
<isd>
I should finish the mass-backup pr. I feel like I got stuck on something but can't remember what...
<JacobWeisz[m]>
That's awesome, Ian.
<JacobWeisz[m]>
I think Kenton wanted progress UI?
<isd>
I think I'd floated the idea initially.
<isd>
that sounds right though.
<isd>
anyway, today I'm working on seccomp.
frigginglorious has quit [Remote host closed the connection]