Starting a community-maintained Tildes source code fork
It's happening: We're launching a community-maintained Tildes source code fork!
Link: https://gitlab.com/tildes-community/tildes-cf
@Bauke, as one of the top Tildes open source contributors, is on board as a co-maintainer, alongside myself. I hear @cfabbro is willing to help manage the issue tracker as well, continuing their long term efforts from the official repo.
Tildes' admin, @Deimos, has direct access to the repository as well. Although he is not expected to take an active role in maintaining this community fork, he will have visibility into everything going on with the fork.
Why?
Deimos has a lot going on outside of Tildes. We want to keep the Tildes codebase well maintained and remove some burden from him.
Back when he founded Tildes, Deimos was working as a fulltime unpaid volunteer on it, continuing that way for a few years. Not just code, but on everything administrative and financial; public relations, as in communicating officially inside the community and beyond; moderating the community; system administering the systems. Basically a ridiculous amount of effort for one person.
Now Tildes is a side project, and he has a day job, and there is not physically enough time for a (human, non-drug-reliant) owner to do all those things.
How will this new fork affect the Tildes website?
The hope is that Tildes can merge relevant changes back into the official upstream repository. If we implement things useful and desirable for Tildes, it should be possible to get those improvements onto the website.
Why not just add maintainers to the official repository?
There are some features that may be desirable for the community, but not relevant to Tildes itself. This includes things like a Docker development environment, which code contributors may find convenient, but are an extra maintenance burden on the official Tildes repo, as Tildes does not use Docker in any way (AFAIK).
Adding us to the official repository would also create a different dynamic, where there'd be an implicit endorsement by Deimos of all changes. This means the burden would essentially remain on the Tildes administrator to review, critique, and greenlight every single change. However, the entire point of this endeavor is that there isn't free bandwidth for that.
Also this fork opens up possibilities like making the code reusable for self-hosting entirely new websites based on the Tildes source code. While I don't personally have any specific plans regarding such, self-hosting has been a repeated request ever since Deimos open sourced Tildes years ago.
Is "Tildes Community Fork" good enough of a name?
Thanks for reading this far! The fork needs a name. It will live in the "Tildes Community" GitLab group at https://gitlab.com/tildes-community/.
For now I've simply called it "Tildes Community Fork" and put it at https://gitlab.com/tildes-community/tildes-cf.
Any better naming ideas? It's not too late to change.
Next steps: We'll start migrating GitLab issues over
I think we're ready to start copying any "low-hanging fruit" issues from the official issues to the new community fork issues. If you have an issue you think qualifies as such, especially if it was ever labeled as "Approved" in the past, please feel free to copy it to the new issue tracker. Please link back to the original too.
It's still a side project for us
Please keep in mind it's still a side project for us. Although we're excited to push the project forward, please keep expectations in check. We're doing this as volunteers. Please be polite and don't rush us!
This sounds like a good idea! Eager to see what becomes of it.
Has Deimos indicated this is something he will facilitate, or is it just a hopeful wish at this time? I like the idea of a constellation of sites running their own Tildes instances, but I’m mainly concerned about the ongoing development of this site.
I'd say it's a hopeful wish for now. Deimos seems generally cautious in committing to unclear things IMO. But he also hasn't outright rejected the idea of the fork. We end up with a chicken-and-egg situation, because how can he positively commit to something when it's unclear what it looks like, and how committed we are to maintaining it?
So I decided screw it, let's just do the fork, prove the quality as best we can (such as a live staging server, getting more eyes on the codebase, etc.). After it's proven, it's much easier for him to commit to pulling changes from it. Worst case, he doesn't want it, and well, it just remains a fork. Individual commits can still be resubmitted to the official repo, and it's all open source and AGPL, so it's available and up-for-grabs if he wants.
I share the same questions. I'm legitimately interested in contributing to development if there's a convenient docker set-up, but I'd like to be able to immediately give back to this site with features I've wanted to see implemented.
How will the forked repo be used and how will changes be merged back with the main site? Is adding these new development tools to the main repo that much of a hosting or maintainence burden?
A while back I had considered contributing some things, but the development environment setup was just big enough a hurdle that it prevented me from using what free time I had to contribute. If this process gets
easiermore familiar with some docker infrastructure, I might have some bandwidth to contribute!The bigger hurdle was that it seemed like the repository was stagnant, and no contributions would be accepted anyway. That feeling isn't really gone here, and after spending more time on the site I'm not sure I really want it to be. There are indeed positives to moving slowly, but I worry the big negative is that it makes contributions feel uninvited. Things appear too stationary at the moment - but that doesn't mean things ought to move too quickly instead.
We'll see. You are probably right that there's this chicken-and-egg thing, and the only way to begin is by beginning.
As for names: Backticks. Being the other, unshifted, symbol on that key, at least in ANSI layouts. Like a sort of lower-cased tilde in some way. It's not The Tildes repo, but a tildes repo.
An alternative would be Graves but that seems... grim.
Edit: I see now that @balooga has already suggested Backticks. Oops! Great minds think alike, I suppose; I endorse their suggestion!
There is also the "perispomene" (circumflex) accent mark in Greek, which looks like a tilde:
https://el.m.wikipedia.org/wiki/%CE%A0%CE%B5%CF%81%CE%B9%CF%83%CF%80%CF%89%CE%BC%CE%AD%CE%BD%CE%B7
An idea for the name: going with visual symbolism, specifically regarding the tilde symbol itself. Starting from the premise that one of the possible aims is to make Tildes' codebase reusable, we could end up with a loose network of communities sharing this common base, expanding like a wave in water, if you will. Hence my name suggestion: Tildes Wave.
I like that. Just throwing some things at the wall because Tildes Wave is good.
Wave ~ a Tildes fork.
Wavey.
Billow.
Surf.
About.
Titulus. If you want to be literal.
Approximately Tildes.
Backticks. It’s a bit of a shift away from Tildes.
Backtick is good (and I like your addition "a shift away") but is an overloaded term; there is/was an under-development Tildes iPhone app named Backtick.
I like approximately tildes, not as a name really but purely because it could be stylized as ≈ to parallell ~
It's would also be a funny acknowledgement that the different groups aren't always 100% clear cut what they include.
EDIT: I guess ≈ is technically also a very very small community of tildes. Just the two of them.
I like Approximately Tildes too. It's funny.
Ripple
Tildes Hydrological Cycle.
If we're going for that angle, there's also the option of calling the fork Delta, as a nod to both river deltas and the mathematical meaning of delta meaning difference
Ooh, I like that!
Edit: I just noticed my idea forms a certain acronym. I truthfully did not think of, nor notice this until just now. Humorous though.
To be honest I completely missed it too... otherwise I'd definitely have jumped on that to suggest "Community Based Delta".
Squiggles
(I'm not sure if I would even like this suggestion if someone else posted it, but it's how all well-educated people name the ~ symbol in their head, right?)
Thanks for getting the ball rolling on naming ideas. Tildes Wave is pretty good; I like Wes's suggestion of Wavelet which is similar. The downside of Wave is that's under contention as the Official Name for a Tildes User so it might get confusing.
(Just an in-joke from early Tildes. There's like one person on the site who thinks Tildefarians should be called Waves instead.)
I find this a very amusing coincidence because the train of thought that eventually became this suggestion started a couple of days before this thread while I was pondering what could be a fitting name for Tildes users. I guess this bumps that count up to two? :)
In French, (one of) the word for waves is “ondes”. That lends itself well for a very nice portmanteau: « tildondes »
I'm straying away from the main subject, but that brings up an interesting idea for a potential localized name for Tildes in French. Given the symbol that gives the website its name has been chosen because UNIX convention associates it with the user's home directory, and the French word for home being "maison", the two could be associated with the portmanteau Maisondes. I certainly like the image it evokes, at least.
Though if the matter of localization ever comes up, there would be a much stronger argument for simply keeping the original name since the ~ symbol has the same name in French, pronunciation included.
This makes a lot of sense, and I'm excited by the prospect of tildes.net receiving updates again. I know we have a lot of developers here who would be willing to contribute, if upstreaming ends up being workable.
As for the name, are there any trademark concerns about using the name "Tildes"? Just spitballing, but the name "Wavelet" feels nice. It matches the tildes and spectrum naming, and by definition is something that begins at one point, fluctuates (makes changes), then returns to its starting point. Sort of like a fork you hope to upstream.
Nice, among the suggestions so far I'm partial to "Wavelet" based on your reasoning of it. It's like Wave but with a science twist. Definitely not going to help with the site's STEM reputation, but it's a source code repo so that's fine.
"Wavelet" also has the advantage over "Wave" of not matching an existing commercial service's name (or a defunct one), if this matters. If the idea of communities using the fork as their codebase does gain traction, calling those spin-off websites "Wavelets" does seem fitting and flows naturally in a conversation.
I agree. “Wave” feels very generic to me and has a lot of preexisting collisions (anyone remember Google Wave?), but “Wavelet” is specific and feels good to me.
Silly question from someone not as tech savvy as everyone else - how will this effect me as a user, and specifically a user of Three Cheers for Tildes? I know talklittle is the creator of TCFT so I would assume things would work out?
No effect. More detailed thoughts in the next paragraphs.
Note, I am not presently associated with this project, just my interpretation from reading this post.
As someone who likes to think of themselves as tech savvy / works as a software engineer - this doesn’t appear to be anything that will affect you, a normal user of tildes (via the app or otherwise) in any way shape or form…except that Tildes may get slightly more frequent updates, if things are contributed to this fork that Deimos likes and wants to pull over to Tildes.
This isn’t something for “users” of Tildes, just something for those who may want to contribute code/features to Tildes. (It may result in spin-offs of Tildes at a later date, as it will make it easier to run a Tildes-like website, but this project doesn’t appear to have that as a primary goal).
Thank you for clarifying, I really appreciate you taking the time to lay it out like this.
Think of it like an R&D lab for things that could be used to improve Tildes as a platform without Deimos needing to personally endorse every single aspect, giving him the possibility to cherry-pick what he likes back to Tildes while still allowing to experiment with features that might not fit Tildes specifically but might still make sense for someone considering it as the base for their own community, or that Deimos simply doesn't have the time/resources to commit to. There will be no direct impact for you as a user, aside from the potential of TCFT keeping up with Tildes' development more seamlessly than before. The most far reaching change I could foresee would be if the following were to happen:
But this outcome is purely speculative.
I’m concerned that “cherry-picking” features into the upstream repo is going to become increasingly complex over time as the two codebases diverge. If the goal of this project is to take some of the pressure off Deimos, it will have the opposite effect in this regard.
Wild speculation ahead because I’ve never actually looked at the code and don’t know what would be entailed:
Could the initial work in the new fork be to rearchitect it to be fully modular and themeable, with everything based around a plugin engine of some sort? But with an explicit goal of leaving all the existing functionality unchanged and introducing no new features? I’m sure that would be a heavy lift. But it might be worth it, if it effectively isolates features from each other. Deimos would need to migrate the site to that new backend (also a big risk on his part) but after that it would be a lot simpler to pick and choose what community fork code gets promoted to tildes.net. It would also foster an ecosystem of plugin development, a bit like WordPress.
As long as I’m making ridiculous pie-in-the-sky suggestions, this would also be a good time to introduce federation protocols. Some way of allowing separate Tildes instances to communicate with each other. That might mitigate some of the community splintering that’s bound to happen as people start spinning up their own clones.
It's not a complex or messy system yet since it's a fresh codebase. Just hasn't had time for scope creep and spaghetti code to fester, or for arguments about features to lead to separate major forks with incompatible changes. Backporting things will remain pretty simple until there are a lot of devs working on the fork generating a lot of new code on a regular basis... something I'd file under 'exemplary problems to have' at this point. I'd expect Deimos' backports to look more like a nip/tuck triple check done after the feature is already optimized in the new branch.
This is the real million dolla question. It would be a very good idea to explore the concept of having nodes co-operate with each other. I expect when/if this project finally pops into view for the regular internet user, it's going to spark the interest of a lot of people who want something close to one-click with docker to try out. We can have that when they go looking for it, or we can look like another slapdash open source project that wasn't fully cooked at launch. More users means more eyes, more code, more donations for all of the nodes - I'd say it's best to be ready before they get here and not waste their time when they do.
Two things come to mind about associating nodes. The first is the idea of having nodes keep track of each other, at a minimum something like an index or a web ring or some other Tildes-to-Tildes method of free association.
The second is the concept of having nodes push content between each other in some way, moving threads around between nodes usenet-style, or even supporting PMs from user@node to otheruser@othernode. We are not ready for that and won't be for a long time.
The simple reason is we can't even push threads up and down a group's hierarchy with the basic mechanics yet. A lot of the systems are simple stubs at this point - good enough for getting a site up. If we don't know how that sort of self-moderated community-curated publishing mechanic works on a single node, and have enough genuine real world test use of it to know how and why it works, we can't begin the next step of publishing that content between multiple nodes in some sort of federation model.
I'd say snag and bag the low hanging fruit. Maybe not web ring per se (though I do like the throwback nature of those), but something... anything that isn't just generic search engine results and lists of dead nodes posted on other forums and central wiki that no one updates. It would be beneficial to get ahead of that predictable mess with a better solution, and before Tildes gets those fifteen minutes of fame.
Edit: In fact, having the index just there available for any app to use does make for an effective way around using search engines and forum referrals. Just give the apps the ability to bundle it in. I'd like to hear what @talklittle thinks about this. What's the 'click to join' solution for an admin setting up a tildes node to list themselves in an index that every app/node can use?
I'll throw my opinion into the ring.
I don't want any sort of federation for tildes (the website).
Federation is a fantastic idea, and Mastodon is pretty interesting, but not everything needs to be federated. I think tildes is good because it is not federated. I am not against some central repository of tildes (the software) instances, but I don't think tildes (the website) benefits from any further interaction with them. A webring or similar is the most that I, as a user, would like to see out of tildes (the website).
I’m also not sure how federation works with the site’s privacy focus. I joined the fediverse briefly and then realized it’s sort of a privacy nightmare, as my content was being duplicated across dozens of servers, including some that could have been acting maliciously.
I’m not technical enough to know if there’s a good way to do “privacy preserving federation,” but I lean towards a centralized model as being better in that regard. Consider our recent discussion about deletion of user content and how that would become a substantially more complex problem if Tildes were federated.
I'm of a similar mind in some ways. It would definitely depend on implementation, but I think a lot of people here on tildes have mentioned the 'old internet' and how it used to be, and while I have no clue the portion of users that have experienced it or prefer it that way, it seems to be a lot more than just a few users. In that regard, federation would be trying to incorporate some of the mixed bad/good elements of the new internet into tildes, namely the centralization and ease of endlessly browsing/scrolling.
I get that federation is sort of meant to de-centralize so it sounds odd to say it enables centralizing, but I don't mean that it centralizes the infrastructure, it centralizes the user experience more. Regardless of where you go in the decentralized infrastructure, you may be likely to see many of the same things (I get that there's a number of factors that can change this, but speaking generally to what I would expect the common experience to be). That's not always a negative, but it seems part of what works or what people seem to like about tildes is that it's more limited in scope. Instead of trying to do everything and be everything, be great at some specific things. That's better than trying to be the everything platform for everyone. Of course, it will never compete at scale with the likes of reddit or tiktok or any other platforms that do try to be the everything platform for everyone.
Federation complicates the community management and increases code complexity, but just allowing nodes to associate gets us a lot of the benefits of federation without having to bother.
Any chat about federating things on a deeper level can wait until well after the Tildes software is 'finished'. It's like trying to put a sky deck restaurant on top of your skyscraper before you've even built the first ten floors.
I think the focus has to stay on providing people a forum/reddit hybrid they can host themselves. Solve the moderation problem, build the systems that improve community function, figure out how to become the ultimate gardener of threads and long discussions. Build the thing that everyone is using because they are sick of corporate social media and they'd like to take back control of their own spaces and projects again.
I like your thoughts on how to discover new nodes. I haven't thought that far ahead honestly, but the webring analog would be a rather straightforward and useful feature. It's essentially a curated list of "friend" sites, curated by each site operator. That's a good way to go, and if we implement it, we'd want to keep that approach going as long as possible. Curation is much more desirable than any comprehensive/automated index.
A full index of all sites isn't that useful IMO. For one, it's easy to game/bot it. Secondly it overwhelms users with too many options. May as well rely on traditional search engines at that point. Even so, I'm sure someone would attempt the full index anyway.
Re: federation, yeah that's not happening with this fork. It would require a ground-up rewrite of most of the architecture. As others brought up, privacy is a major issue and is a showstopper for adding federation to Tildes. On Tildes, if you want to communicate privately, you need to trust one admin. Federated, you shouldn't really do private communication, because there's no way to trust every operator. End-to-end encryption could be used there, but is an inconvenience for the general user, and can result in lost and unrecoverable accounts.
I don't hate federation. I am interested in it. Excited that there are huge efforts underway in federated apps being built. But not everything has to be built the same way following the fads. We'll go with the easy-to-understand, easy-to-operate traditional web app here.
I've been sitting on two custom themes for months now, planning to make a pull request for them. They're just themes, nothing complicated. I guess now I should open a pull request for them on the community repo instead of the main repo?
Good question. We'd be happy to look at the pull request on the community fork.
The official repo might be appropriate for urgent pull requests (security etc.) or very simple pull requests that are of obvious value to Tildes.net. Especially if someone has been in contact with Deimos and he's agreed to review the specific request. Otherwise, like in this case with themes, I'd probably just submit to the community fork.
We have yet to figure out the exact mechanism where changes will be backported upstream. Maybe it'll involve a staging server where the changes can be easily viewed live. We'll need some time to set that up as well.
So, will that be an actual website people can use? Or just a codebase that would allow anyone to deploy Tildes? Sorry for the stupid question, I'm not a developer.
If this is an actual website, I would suggest keeping it in line with the minimal design philosophy of Tildes. Beehaw is not a Tildes fork but it was made by people who used to be on Tildes. I think they're lovely people but the website is kind of a mess. So I would suggest avoiding that.
I think it's okay to call this "The Tildes Community Fork", or "The Tildes Fork", or "The Fork". Tildes is very literal so it makes sense for the fork to be literal as well.
Someone already answered but just to confirm, the main point is to get changes back to the main Tildes website. There is no plan to create a new website.
However, this restructuring of code might make it easier in the future for new websites to be made, because having a separate codebase means we're not limited to features that solely work on Tildes.net. Again, it's not a top priority though.
They're taking the existing code of Tildes and making it easier to run another copy of it. It doesn't sound like they intend to replace tildes.net.
can we call it GILDES?
Okay I'll bite: Why GILDES?
its an older spelling of 'guild' and rhymes... nothing else to it. If I were actually picking a name, I'd just call it Tildes-CF like you did.
Interesting, but I don't see much changing here. Instead of slow updates with requests being slow to worm on, we'll at best now have a huge backlog of PR's to not get approved to begin with. Since part of the goal is to "not be officially ordained by Deimos", that'll inevitably slow down any potential development as an official maintainer (who may or may not be Deimos) will debate over various designs and philosophies.
Ofc the worst case is another dead/stale fork. A fork that may have had more leeway if they had official contribution on the main fork.
Nevertheless, I wish you the best of luck. It would be nice to have some larger update posts than that of recent years.
Genuinely awesome news! Y’all are heroes.
As someone currently in the middle of migrating our internal company Python codebase to the Future™ with the Astral toolset (
ruff,rye, anduv) on top of containerizing everything for GKE, all I can say is best of luck with the fork. I'm more suited to YAML engineering Kubernetes than digging in with Pyramid.I'll pop in with some PRs when free.
Sounds like a nice community project! I hope it all works out nicely.
Self-hosting my own mini Tildes actually sounds interesting, I might look into it in the future.
Ya know, I think this is ridiculous and unnecessary. My entire career as a DevOps nerd has taught me containers are a FAD. Not one of my worst devs uses the containers I write for running their apps on servers or k8s. They keep using the local builds without even so much as a version manager.
Containers are a FAD. You don't need one for the tildes development environment. Stop being such a bandwagoneer!
/s
Containerizing the development environment is merely a stepping stone. The end goal is for each Tildes user to be represented as a Docker container. Reading and posting to a topic requires mounting the topic's volume first. All access to Tildes will be via a mesh network of containers. You can host your container on your own PC or have a friend host yours for you. We'll also offer a hosted option for a monthly fee. /s
This disrupts my workflow.
That got a surprise laugh-snort out of me. I'm glad it wasn't at the moment I was sipping my drink.
I know it was a joke, but it hurt my soul to read this lol
You had me going for a second there, I'm glad I skipped to see the
/sat the end before I started to lose it.