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?
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
Thank you! :fidel-salute:
deleted by creator
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.
🙏🙏🙏