I'm not hyper-savvy, I'm no engineer.. But where's the Lemmy unity? Like it kind of sucks ass if chapo rather than contributing to all of the Lemmy code base just goes fork & does it their own. Like I find it super hard to believe that Lemmy built themselves into a corner whereby their language of choice doesn't allow 10k+ users or makes it extremely hard to pull that off? That seems really surprising to me.
Like even if it is technically some amount harder to overcome X, Y, Z issue - shouldn't the fact that y'all would be contributing those fixes globally thru the Lemmy ecosystem be worth alot? Especially considering the whole framework from which this site spawned is based on their hard work?
Again, I'm not an engineer & I don't natively know these things - but to me it sucks hugely that Chapo is going our own instead of broadcasting helpful updates back & forth. Maybe the fact that I'm not an engi makes this feel like the antithesis of leftist[Lemmy] unity
Also Jah bless all the devs, yall are fucking amazing
The specific language of choice here doesn't matter for scaling to 10k+ users- rather the decisions and implementation details of said language. Early Lemmy had some pretty bad performance issues at low user counts (100 concurrent?) due to some database queries and other choices. Some of the devs working on Chapo helped upstream fix those, but a lot of the early janky, sluggish and "bad" feeling performance of Chapo was due to decisions that upstream deprioritized or did not want to implement in favor of federation- which is fine! But we had to continue to prioritize those changes and the brick wall we hit is that finishing those out in rust is cumbersome and we've already deviated so far that merging changes between the two projects is a large effort. We plan to still contribute upstream on critical issues like these when possible, but by nature of our instance size we have to take a different prioritization path and likely will for some time.
The other side to this is that, yeah, anything is technically possible, but some choices make it a much more difficult road than others and at the end of the day we're merely lefties struggling under the boot of capital- so it makes sense to make the "technical road" as easy and effective as possible to combat engineer burn out or Life Happening.
Does this make the technical road easier long term though? From fork on it's just chapo devs working @ it - whereas with the same lemmy base it's chapo devs + Lemmy devs. Whabbout a world where Lemmy devs massively outnumber Chapo devs & are far more productive?
Your explanation does a great job of explaining how/why we got here - 2 different totally understandable priority sets, and neither chapo nor Lemmy are wrong for prioritizing one or the other. Makes sense that they'd prioritize federation as that's really scaling just by another name. Makes sense that hex would opt for scaling RIGHT NOW when the user influx is/was upon us.
I guess I just question if long term going forward in this way & sort of doubling down on code base incompatability is the right decision - again from my non-technical un-educated derivative viewpoint.
codebase is already at a huge state of incompatibility because of changes we've implemented so far. when i take features upstream i can't really even pull our code into theirs easily. i pretty much just have to copy/paste the code over to a new file on their codebase and rewrite some pieces to match up.
this is also why we have not merged upstream for a while. it's...a huge task. incredible amount of merge conflicts.
if we were to continue maintaining the current fork while also trying to merge upstream into our codebase and also send features upstream...i personally would have hit such a large state of burnout i may not have been able to come back from.
i'm still going to work on lemmy too, but instead i'll just be translating typescript to rust.
why doesn’t the larger hexbear simply eat the lemmy?
why don’t they merge/adopt our code? ya’ll have basically upscaled lemmy operations for 10k concurrent users; wouldn’t it be better if any lemmy can serve 10k concurrent?
not much we can do about diesel's (one of the rust tools) lack of features. if we can build them with tooling that does what we want to do, we can get something working and well tested and then try to work around diesel for upstream
Truly fascinating stuff and my biggest regret is really not learning to code more than just python scripts, which I could help. I guess if ya’ll needed a document writer I could donate some time next year >_>
any and all help is appreciated. sometimes it's something like someone picking up documentation tasks or writing up bug reports from less-technical users that can take a lot of stress off of devs _
Long term I think the general overlap of people who know JS and ideologically agree with Lemmy will be greater and more sustainable than that of Rust- And with that said Rust itself is still very young in web dev space so even for a project as "simple" as this one we have hit annoyances, things that are unsupported or undocumented but are things that are trivial in other languages. So part of this long road is factoring in that a systems lang just "isnt there" yet and maybe wont be for years and will certainly put a damper on being productive or sustaining the dev pool.
The other thing to be aware of is code base incompatible is a relatively minor issue here. Federation relies on "activity pub" which is an open web standard for communication and so the only thing we really have to do is make sure we match the activity pub spec and that "hexbear objects" can translate to "lemmy objects", which they will because 'users', 'posts', 'comments', etc are pretty simple things to model and it's not technically difficult to add custom "extensions" to them that don't interfere (and we've already had to do this to prevent this instance from crashing). So I would think of it less about the codebase itself, but rather that we "communicate" the same way. That would only be a problem if upstream decides to stop using apub, which would be a breaking change to every Lemmy instance so it's rather unlikely.
Roger, that makes good sense. Thanks for the clarity re: federation & it just being a web standard that's easy enough regardless of code base interop.
Y'all are so fucking badass, it rules that some doinkus like me can ask for clarity & get such engagement and willingness to explain. Such an amazing ethos, it's really somethin.
Huge commends to all of you for taking the time not only to build, but to explain & discuss & consider. ❤️❤️❤️
No problem and feel free to ask anything anytime. It's part of why we made this comm and these are all perfectly valid questions to have. The secret is...we're all some doinkuses ourselves
So are there no upstream efforts for stickers or the likes? I'd imagine they'd be pretty popular considering most chat apps and current social media platforms support them.
It'd be a shame if our custom emojis only interacted with instances that are a fork of ours...especially given Lemmy is probably going to be the most-forked implementation.
Side question: where is the tool to create new emojis?
There's a very real possibility that the Hexbear fork ends up getting used by other sites instead of Lemmy, and eventually Hexbear ends up the 'main' project. This sort of thing happens a bunch with open source projects.
There's also a lot of value to the Lemmy ecosystem if there are a lot of independent(-ish) implementations of the Lemmy federation standard. The more different pieces of software that interact with the same API, the better, in general -- it forces the API information to be more standardised and specific, and encourages new reddit clones to also be Lemmy-compatible.
I'm not hyper-savvy, I'm no engineer.. But where's the Lemmy unity? Like it kind of sucks ass if chapo rather than contributing to all of the Lemmy code base just goes fork & does it their own. Like I find it super hard to believe that Lemmy built themselves into a corner whereby their language of choice doesn't allow 10k+ users or makes it extremely hard to pull that off? That seems really surprising to me.
Like even if it is technically some amount harder to overcome X, Y, Z issue - shouldn't the fact that y'all would be contributing those fixes globally thru the Lemmy ecosystem be worth alot? Especially considering the whole framework from which this site spawned is based on their hard work?
Again, I'm not an engineer & I don't natively know these things - but to me it sucks hugely that Chapo is going our own instead of broadcasting helpful updates back & forth. Maybe the fact that I'm not an engi makes this feel like the antithesis of leftist[Lemmy] unity
Also Jah bless all the devs, yall are fucking amazing
The specific language of choice here doesn't matter for scaling to 10k+ users- rather the decisions and implementation details of said language. Early Lemmy had some pretty bad performance issues at low user counts (100 concurrent?) due to some database queries and other choices. Some of the devs working on Chapo helped upstream fix those, but a lot of the early janky, sluggish and "bad" feeling performance of Chapo was due to decisions that upstream deprioritized or did not want to implement in favor of federation- which is fine! But we had to continue to prioritize those changes and the brick wall we hit is that finishing those out in rust is cumbersome and we've already deviated so far that merging changes between the two projects is a large effort. We plan to still contribute upstream on critical issues like these when possible, but by nature of our instance size we have to take a different prioritization path and likely will for some time.
The other side to this is that, yeah, anything is technically possible, but some choices make it a much more difficult road than others and at the end of the day we're merely lefties struggling under the boot of capital- so it makes sense to make the "technical road" as easy and effective as possible to combat engineer burn out or Life Happening.
Does this make the technical road easier long term though? From fork on it's just chapo devs working @ it - whereas with the same lemmy base it's chapo devs + Lemmy devs. Whabbout a world where Lemmy devs massively outnumber Chapo devs & are far more productive?
Your explanation does a great job of explaining how/why we got here - 2 different totally understandable priority sets, and neither chapo nor Lemmy are wrong for prioritizing one or the other. Makes sense that they'd prioritize federation as that's really scaling just by another name. Makes sense that hex would opt for scaling RIGHT NOW when the user influx is/was upon us.
I guess I just question if long term going forward in this way & sort of doubling down on code base incompatability is the right decision - again from my non-technical un-educated derivative viewpoint.
It rings my sunken-cost fallacy bell
codebase is already at a huge state of incompatibility because of changes we've implemented so far. when i take features upstream i can't really even pull our code into theirs easily. i pretty much just have to copy/paste the code over to a new file on their codebase and rewrite some pieces to match up.
this is also why we have not merged upstream for a while. it's...a huge task. incredible amount of merge conflicts.
if we were to continue maintaining the current fork while also trying to merge upstream into our codebase and also send features upstream...i personally would have hit such a large state of burnout i may not have been able to come back from.
i'm still going to work on lemmy too, but instead i'll just be translating typescript to rust.
From the depths of my soul thank you for all your hard work comrade.
I really regret not listening to the libs who said "learn to code."
there's still time ;)
why doesn’t the larger hexbear simply eat the lemmy?
why don’t they merge/adopt our code? ya’ll have basically upscaled lemmy operations for 10k concurrent users; wouldn’t it be better if any lemmy can serve 10k concurrent?
not much we can do about diesel's (one of the rust tools) lack of features. if we can build them with tooling that does what we want to do, we can get something working and well tested and then try to work around diesel for upstream
Truly fascinating stuff and my biggest regret is really not learning to code more than just python scripts, which I could help. I guess if ya’ll needed a document writer I could donate some time next year >_>
any and all help is appreciated. sometimes it's something like someone picking up documentation tasks or writing up bug reports from less-technical users that can take a lot of stress off of devs _
Long term I think the general overlap of people who know JS and ideologically agree with Lemmy will be greater and more sustainable than that of Rust- And with that said Rust itself is still very young in web dev space so even for a project as "simple" as this one we have hit annoyances, things that are unsupported or undocumented but are things that are trivial in other languages. So part of this long road is factoring in that a systems lang just "isnt there" yet and maybe wont be for years and will certainly put a damper on being productive or sustaining the dev pool.
The other thing to be aware of is code base incompatible is a relatively minor issue here. Federation relies on "activity pub" which is an open web standard for communication and so the only thing we really have to do is make sure we match the activity pub spec and that "hexbear objects" can translate to "lemmy objects", which they will because 'users', 'posts', 'comments', etc are pretty simple things to model and it's not technically difficult to add custom "extensions" to them that don't interfere (and we've already had to do this to prevent this instance from crashing). So I would think of it less about the codebase itself, but rather that we "communicate" the same way. That would only be a problem if upstream decides to stop using apub, which would be a breaking change to every Lemmy instance so it's rather unlikely.
Roger, that makes good sense. Thanks for the clarity re: federation & it just being a web standard that's easy enough regardless of code base interop.
Y'all are so fucking badass, it rules that some doinkus like me can ask for clarity & get such engagement and willingness to explain. Such an amazing ethos, it's really somethin.
Huge commends to all of you for taking the time not only to build, but to explain & discuss & consider. ❤️❤️❤️
No problem and feel free to ask anything anytime. It's part of why we made this comm and these are all perfectly valid questions to have. The secret is...we're all some doinkuses ourselves
What are the plans for our custom emojis when federation is implemented? I'm not familiar with the details of the ActivityPub spec.
deleted by creator
So are there no upstream efforts for stickers or the likes? I'd imagine they'd be pretty popular considering most chat apps and current social media platforms support them.
It'd be a shame if our custom emojis only interacted with instances that are a fork of ours...especially given Lemmy is probably going to be the most-forked implementation.
Side question: where is the tool to create new emojis?
deleted by creator
deleted by creator
Thank you! :fidel-salute:
As a software engineer, in this case the sunk cost fallacy would favour trying to keep with lemmy code.
This isn't that world, lol.
🙏🙏🙏
There's a very real possibility that the Hexbear fork ends up getting used by other sites instead of Lemmy, and eventually Hexbear ends up the 'main' project. This sort of thing happens a bunch with open source projects.
There's also a lot of value to the Lemmy ecosystem if there are a lot of independent(-ish) implementations of the Lemmy federation standard. The more different pieces of software that interact with the same API, the better, in general -- it forces the API information to be more standardised and specific, and encourages new reddit clones to also be Lemmy-compatible.