Congrats on the milestone. This is a huge boon to the open source community. I love the pricing model.
Are there any plans or ideas for a migration path from GitHub to sir.ht? I would imagine that if there was a way to transfer issues and discussions it would encourage more users to make the switch.
Here's one data point for you: zig programming language. Influencing factors:
* If we had syntax highlighting in the file browser, that would be a win over GitHub, which insists that there be "hundreds of GitHub repositories" before accepting a syntax highlighting pull request for a new language. I could imagine it would be reasonable to support "repository-local" highlighting configuration.
* Transferring existing content as mentioned above. It would be unwise for us to give up all the issues and discussion.
* The fact that the build service supports FreeBSD is already a win. However, to switch from Azure DevOps we would lose Windows builds. Is that ruled out due to the open source nature of sr.ht, or is that planned? Related, it would be attractive if sir.ht offered more architectures, e.g. i386, ARM, RISC-V (I believe this was mentioned but I could not find it in the docs)
>* If we had syntax highlighting in the file browser, that would be a win over GitHub, which insists that there be "hundreds of GitHub repositories" before accepting a syntax highlighting pull request for a new language. I could imagine it would be reasonable to support "repository-local" highlighting configuration.
We use pygments, so patches to pygments would make it to sr.ht's syntax highlighting.
>* Transferring existing content as mentioned above. It would be unwise for us to give up all the issues and discussion.
Planned. Also planned to let you sync between both.
>* The fact that the build service supports FreeBSD is already a win. However, to switch from Azure DevOps we would lose Windows builds. Is that ruled out due to the open source nature of sr.ht, or is that planned? Related, it would be attractive if sir.ht offered more architectures, e.g. i386, ARM, RISC-V (I believe this was mentioned but I could not find it in the docs)
Eventually users will be able to add custom base images, which will permit the use of Windows (if you can get an sshd running there, at least). As for multi-arch, experimental support for aarch64 is there, and by the end of the year I expect to have RISC-V builds backed by HiFive hardware.
Nonetheless, it'd be nice to have some way of plugging in more of this kind of functionality at the instance, user, and possibly repo levels. Obviously syntax highlighting is one use case, but some others:
- Sophisticated cross-referencing tools like Kythe and SourceGraph
- Linking stdlib functions and imports to public documentation, like cppreference.com, python.org, etc.
- Linking ticket/user names to my non-srht bug tracking tool (especially JIRA, but there are lots of possibilities).
- Linking to public or self-hosted generated API docs (doxygen, swagger, sphinx, etc).
- Linking to info pages generated from metadata-type files such a PKG-INFO (for example containing dependency tree information).
- Propagating back information gathered from build or test runs, for example highlighting areas missing test coverage, or which are "hot" from a perf point of view.
Only some of these would be appropriate to go into the mainline version of the tool, which is why it's important to support plugging in these capabilities for the users which need/want them.
I think a lot of what you're looking for is going to be possible through generic interfaces I plan on writing. It's not going to take the shape of "you can write code which executes on sr.ht's servers just for your repo in particular", but rather things like "you can POST to an API endpoint on git.sr.ht to annotate the sources in your tree for a specific commit sha with links to pydoc et al". builds.sr.ht would then be the place where you could run arbitrary code to automate this.
Sourcegraph CEO here. We would love to help integrate Sourcegraph into sr.ht for code intelligence (hovers, go-to-definition, etc.). We’re kicking this off with GitLab next month.
I'm sure it's lovely, but where is it? I can't see any mention of pricing in the blog entry, or in https://meta.sr.ht/, and the top hit in Google for "sr.ht pricing" is... your comment.
- It's left aligned, which makes it harder to use on an ultrawide, with the content in the first 1/3 of the page. Having a max-width on the main container and center aligning it would be great
- Emails are GPG signed! Even if the usefulness is small, it's a awesome feature
- Pricing seems good, but I would charge more. 3$, 8$, 15$, if following the pricing scheme you have. I know I'd be happy to pay for 15$/m for a useful service. You could also make it "pay however much you want", so it's flexible if people want to pay 5$ or 50$, and it calculate with the tiers (if over X$, use plan Y)
- It feels very responsive. Great job on having the site being very light so far
- Maybe having something like Turbolinks could be pretty cool. SPA are great because they feel instant, and with a few lines of optional JavaScript you could provide an experience which is SPA-like since the server-side rendering is so quick
- The UI looks clean and minimalistic, which is great. Featureful isn't a bad thing either if done right. I think you're on the right path though
Overall, this seems like a great project. I haven't tried the builds system yet, but I definitely will. Keep up the great work Drew!
>It's left aligned, which makes it harder to use on an ultrawide, with the content in the first 1/3 of the page. Having a max-width on the main container and center aligning it would be great
>Emails are GPG signed! Even if the usefulness is small, it's a awesome feature
Encrypted, too, if you add your PGP key to meta.sr.ht.
>Pricing seems good, but I would charge more. 3$, 8$, 15$, if following the pricing scheme you have. I know I'd be happy to pay for 15$/m for a useful service. You could also make it "pay however much you want", so it's flexible if people want to pay 5$ or 50$, and it calculate with the tiers (if over X$, use plan Y)
I may adjust the pricing later, but I want to see how this works out. If you're interested in going above and beyond, I accept donations here:
>Maybe having something like Turbolinks could be pretty cool. SPA are great because they feel instant, and with a few lines of optional JavaScript you could provide an experience which is SPA-like since the server-side rendering is so quick
Not interested in this for the time being, it's pretty fast without.
I adore the aesthetic! Absolutely smooth web design; top notch work Drew.
Just registered and hope to familiarize myself with everything. This is one of the few "Show HN" projects I've felt compelled to actually try. Heck, I'm so charmed by it I want to contribute.
Always keep in mind that many people have an interest in ensuring their own job remains relevant and necessary. How else can you explain e.g. google's constant UI changes? Designer's keeping themselves busy (even though there are no real reasons for the changes)!
This is really exciting! I particularly like the lightness of the web-pages and the non-necessity of javascript. The support for the BSDs in the build system (FreeBSD at the moment, OpenBSD and NetBSD planned[0]) is also nice — as a Linux person I've far too often ignored the other Unixes and POSIX / general Unix compatibility.
I hate being THAT guy, but would you consider trying[1] to re-license the AGPL-3.0 bits to AGPL-3.0-or-later, unless sticking with just v3 was deliberate (in which case fair enough)? My rationale:
i) License-incompatibility is a curse that fragments the copyleft world.
ii) Worrying about AGPL-3.0-only being incompatible with AGPL-4.0, in ten years time, if/when the latter comes out, will be too late, as (hopefully) sr.ht will have had hundreds or thousands of contributors, many uncontactable, by then.
iii) Having AGPL-3.0-or-later instead of just AGPL-3.0 is unlikely to put off any contributors.
iv) (This is subjective and might not hold for you:) I trust the FSF not to do something sufficiently crazy with its next iteration of licenses (if such exist), that I would prefer my code not to be compatible with such licenses.
> I trust the FSF not to do something sufficiently crazy
Personally, I don't trust this at all, and would recommend against the "or later" that yields future licensing decisions to the Richard Stallman and that FSF.
not speaking for OP, but the significant changes between GPL v2 and GPL v3 would make me absolutely paranoid, and represent a good example. A "v2-and-later" would have subjected people to licensing changes they absolutely don't want.
I love this. Everything I've read so far breathes this "made for devs" attitude. I hope that a few years from now in a HN thread that lists successful companies that got "launched" on HN (you know, the Dropboxes and so on), this will be among them---and that the product is still as honest and awesome as it looks right now!
Don't have an immediate use, but I signed up for the $20/yr account. Seems like an incredible platform, and if I have this expectation that better software be built and not tied to huge corporations beholden to investors, the only way to do that is to support it. Looking forward to digging into all this.
> On top of that, sr.ht is one of the most lightweight websites on the internet, with the average page weighing less than 10 KiB, with no tracking and no JavaScript
At the age of Spectre/Meltdown, it is no longer safe to leave JavaScript enabled, so thank you for this.
Javascript hardly needs help from Spectre/Meltdown to be a security threat. It has never been safe to allow Javascript. A reasonable compromise is to use a Javascript blocker that lets you white-list domains.
Then, keep in mind that new Spectre style vulnerabilities have been announced for CPUs, and the feasibility of using GPUs in this style of attacks is being explored now.
I currently host my personal repositories on GitLab, as I see the monoculture that has developed around GitHub to be dangerous for the community in the long term. I went ahead and created an account on sr.ht, and subscribed for the $20 / year plan. Whether or not I end up using the service (though I think I will), I'm happy to spend $20 to support this work.
One note - the billing plans seem to be recurring right now. If you could offer an option to make a one-time payment, that would be much appreciated. If anyone else is interested in subscribing to support the project but doesn't want a recurring charge on their card, you can go to https://meta.sr.ht/billing and "cancel", which will turn off autorenewal but leave your account active for the term for which you've paid.
For the sake of sustainability, I want to discourage people from using one-time payments. For the time being charge -> cancel manually is the preferred way to do this.
A meta comment on the HN community: People constantly decry HN's "negativity" to Show HN posts or other tech related news, but I think when really cool projects (like this one) show up, people respond overwhelmingly positively. Maybe it's a good thing that HN as a community has high standards.
It would be nice to be able to add custom links to whatever form this navigation takes, also (for example, if a project uses a different solution for code review/patch submission).
Looks like the CI builds are tied to a user/group account rather than being tied to a particular repo or branch. Bravo on that— it works much better for projects whose build is composed of assets from many small repos than the approach of Travis (and GitLab, who cloned it) of tightly coupling those things.
I also like how DFeed looks. It's written in D and simultaneously serves forums, mailing lists, IRC and (lol) Usenet; all on an SQLite backend. It's also compiled to machine code, so it's pretty fast:
With a service like this, I don't understand why a lack of tracking is touted as a feature - I don't want Google et al tracking my search history and across 3rd party websites, but I want to provide usage data to services I value.
Usage data is valuable for understanding how users use your service, features that aren't used, or simply not discovered. I'd personally prefer that tracking was added, but as an opt-in model.
this piques my interest. i've been looking for a set of project hosting and management tools which are deeply integrated with each other and with very minimal UIs designed as an extension of the tool's inherent abstractions, rather than obscuring the tool behind "simple" UI abstractions which ultimately force opinionated workflows.
the only thing that's missing for this to be useful to me is code review. re: the UI, gerrit has always been my favorite code review platform because it embraces git's abstractions.
drew: do you have any plans for adding a code review service?
Hiya! I do have plans on adding a code review service, driven by email on lists.sr.ht in a similar style to how it's done in other mailing list driven projects. Here's an example of how this works:
Forgive me if this is covered elsewhere, but I haven't found it yet.
One of the things that I do like about GitHub is actually the community/social aspect. For example, I follow projects I am interested in, and I can see notifications from all of them on one page--without filling up my email inbox. I also follow users who have similar interests, and I often discover new projects when I see in my feed (which I read via RSS) that they've starred a project that sounds interesting.
I think it's great that you're supporting email as a first-class way to interact with the services, but will there also be anything like GitHub's "Notifications" page?
Another feature I enjoy on GitHub is the ability to view issues and PRs across all of my repos from a single search page (e.g. search for "user:repo-owner-username is:issue"). Will sr.ht have anything like this?
>One of the things that I do like about GitHub is actually the community/social aspect. For example, I follow projects I am interested in, and I can see notifications from all of them on one page--without filling up my email inbox. I also follow users who have similar interests, and I often discover new projects when I see in my feed (which I read via RSS) that they've starred a project that sounds interesting.
For the moment I've explicitly decided against this. I want sr.ht to be a professional tool more so than a social network. This may change to varying degrees in the future.
>will there also be anything like GitHub's "Notifications" page?
There will be a feed of events, which you can use for a similar reason. At the moment, there are feeds like this, but they aren't global - they're scoped to each sub-site, like lists.sr.ht. Here's what my lists.sr.ht page looks like:
>Another feature I enjoy on GitHub is the ability to view issues and PRs across all of my repos from a single search page (e.g. search for "user:repo-owner-username is:issue"). Will sr.ht have anything like this?
Hi, and congratulations, it looks awesome and has that old school unix feel I like, so you have a subscriber here.
Regarding the social/professional divide, a way to follow releases/security patches/API breakages on the projects I follow might make me more productive. I don't care about who stars who, but a way to link projects brings something.
Following releases of dependencies and use this information to improve CI/CD and try to explain breakage or trigger new builds
could be very useful.
I find the ability to subscribe to (and aggregate) notifications on individual issues and projects incredibly helpful, professionally, because it lets me easily keep track of fixes and changes in upstream projects.
You can have email notifications without filling up your inbox. Just set up a filter rule to move all emails from an address to a folder. I do that for all spammy things like mailing lists or issue tracker comments.
One of the coolest projects I've seen in a while! Really excited to see where this goes.
Some quick feedback: viewing messages on lists.sr.ht on mobile gives the "<code> block experience" of moving a horizontal a scroller for every line.
This might be intentional (wrapping can wreck formatting/alignment) but it might be worth wrapping for it to be less painful to read from a mobile browser.
Yeah, this is deliberate. I don't want to wreck the formatting of anyone's emails. That being said, there are solutions to this... but they're a bit obscure and will require some effort.
(oh, the tilde copy-and-pastes weird into the comment window.. not sure what that's about)
This is the "issue page" (in Github speak) for one of a user's repositories. But how do I navigate from there to the actual repository? The 'git' button at the top takes me to generic landing page? I found this link through the announcement page : https://git.sr.ht/~sircmpwn but I dont get how to navigate to there naturally.
Or how to go from the git back to the todo. I get they're decoupled features, but surely there must be a way to go back and forth.
Also when I open up the 'tree' section, each line starts with file permissions in the style of 'ls -la'. Is this b/c the system is fundamentally tied to POSIX? (I've used git with no problem on Windows before - so I don't see why it would be)
>Also when I open up the 'tree' section, each line starts with file permissions in the style of 'ls -la'. Is this b/c the system is fundamentally tied to POSIX? (I've used git with no problem on Windows before - so I don't see why it would be)
Because the file mode is stored in git. The tree view is a representation of the git tree, and the mode is a property stored in the tree.
I remember a discussion with Drew on HN a while ago. I held that the GitHub model was more inviting to small contributions given the overhead of figuring out how to get said small contribution integrated was paid for every new project outside of GitHub(-likes), but only once for GitHub and friends [1] (see discussion at https://news.ycombinator.com/item?id=17803588).
sr.ht takes a very good stab at that problem, while maintaining that old-style approach. (For example through predictable mailing list names, should the project choose to use lists.sr.ht, which is likely.)
Kudos, Drew.
One intriguing thing about sr.ht is the way builds.sr.ht is described: amazingly powerful [2]. It's been a while since I configured myself a Travis workflow, but remember it was YAML based as well and one could do quite a number of things with it. What I'm missing is a description of exactly how builds.sr.ht towers above all the rest.
[1]: By approximation, some projects hosted on GitHub have more specific rules and will not consider those who deviate.
> BTW, please add a nice 404 so people won't see that you're running nginx/1.14.0 :-)
Actually simply adding a custom 404 page won't hide the webserver/version, as it is also sent along the HTTP response headers.
For nginx specifically, one can use the `server_tokens off;` directive, which hides the version (but not the webserver). Brings back memories of when I used to recompile the webserver to remove this header :)
Of course for UX a custom 404 page is great. Congratulations, Sir_Cmpwn, this is just awesome and I'll soon be subscribing.
I have not tried to clone it myself. But if it is not a web-facing URL, you should list it in clear CLI command and remove the <a> tag. People will click if you make it clickable.
One immediate difference is that sr.ht has a publicly-hosted version; I'm having trouble finding that for Trac.
Trac is also not JS-free, so for those who prefer to not rely on arbitrary Turing-complete code running locally without explicit permission, sr.ht has an edge there.
That said, Trac feels a lot more polished (unsurprisingly, given that it has a significant headstart in terms of development resource and time).
Right, Trac has an extreme head start; it was, before Github, practically the de facto standard answer to this "software forge" problem. But it also continues to work just great, and has a pretty decent ecosystem.
Well, almost everything: The "View raw message" feature exposes way too much information about your contributors - including their email, smtp client, ip, and a bunch of other things. I understand and appreciate the usefulness, but as a contributor I don't usually expect my details to become that public.
The IP is the IP of your mail server, which is a lot less private (you can derive that just by doing a DNS lookup on your hostname). The email address is explicitly exposed, your email is not private in git repos either, and it's important that people are able to get in touch with you. It's a mailing list!
Many email servers report the IP of the incoming SMTP connection when you use a client (e.g. mutt, Thunderbird, Apple Mail, or Outlook) as an "X-Client-IP" or similar raw header; often also the envelope "from", which may be different than the message "from" which is the only one usually shown.
It's not that IPs are very private - sending an email to someone often tells a lot about you. But having all that info publicly scrapable seems unexpected to me.
They're ordered by the time you accessed each last. I agree that this is, in retrospect, unintuitive and poorly designed. Will be reverting it soon enough.
Very impressive! The https://builds.sr.ht service looks especially interesting - any chance there's a way to use it without fully moving over to sr.ht? It would be nice to be able to try out the build system without having to fully commit to moving to to sr.ht, especially for projects with a large history on other platforms.
I went ahead and registered and signed up for a plan. If this is the kind of project you like to see, I encourage you to consider signing up to contribute.
Feature request: I'd love to see U2F support added.
This is excellent. I've started moving projects over, and I'm looking forward to shifting from fosspay donations to actually paying directly for this. Excelsior!
I'm not sure why this is a selling point. Yes, there are many upsides to this, particularly from the maintainer's standpoint, but I think it might just be a side-benefit that only certain users really care about. Eventually, there might be advantages to removing that "feature", and you might turn off users who joined largely because of it.
I see it as a reflection of the website's overall design stance: no frills, no stupid material design, no js junk scripts. Just a fast-loading website that loads what it needs to. This kind of website is quite refreshing in 2018.
Maybe one day it will have a tiny amount of JS, but let's cross that bridge when it comes. That's still better than the vast majority of modern websites built today.
Even if it did have JS, I think most of the crowd would be fine with minimal JS also, since there are some legitimate use cases. Having JS is not the end of the world, but today's standard is to completely abuse it, leading to horrifically bloated websites.
I like this design decision. I can't talk for other people, but if a page looks good on a text based browser, I consider it to be well designed page (although I don't force the converse).
The way I understand it, the only real reason why there is something like javascript at all is that one wants to improve latency / computing load on servers. But since javascript is already here, it is now easy to abuse it instead by cluttering all kinds of junk and computing to the page and to the browser / client.
You should make a more thorough comparison with other "100% open source" forges. Your main arguments against GitHub and the like are the license, tracking, and ads. Instead, you make no good arguments for why this tool is so "special" compared to other equivalently free tools. I'm not trying to be a jerk here, but the post looked like a hard sell to me.
I do intend to expand this list, probably with at least Debian packages. This isn't a high priority at the moment, though, I have limited bandwidth for sr.ht until it's profitable and have to focus on other features. This is definitely an area where an interested Debian user could contribute packages, though, especially if nicely integrated with builds.sr.ht like the other packages are.
What's the pricing structure going to be, ie. how much should I expect to pay for hosting a dozen of small git repos? I can't access the billing page without an account.
Thanks for your work for the FLOSS community, btw. I've got one machine running Sway and I might start using sr.ht.
You can choose any of $2/mo, $5/mo, or $10/mo, depending on your financial situation and investment in sr.ht. All plans have access to all features. Here's a screenshot of the billing page:
Thanks for providing this and thanks for allowing us to pay for an account. I hope that sr.ht becomes sustainable, it's great to have an alternative that is focused on open source developers.
Browsing from mobile so not easily able to poke around, hence pardon my ignorance, but what is meant by “software forge”? Is this common terminology? I haven’t heard it before. Initially I assumed this was some sort of web-based IDE, but I guess it’s more of a source control, continuous integration, devops, and deployment system? Is it like Github meets Jenkins meets Jira? It might be valuable to have a more clear overview message on the site.
Edit: The actual project homepage has a much better overview of what this is, sorry for my initial cluelessness. The more I look into it, the more impressive it looks, thanks for the great open source contribution!
One quick bit of feedback: In the audit log, I noticed oauth tokens being issued even though I didn't recall granting any. I had a moment of pause worrying I was breached until I realized it was the various sr.ht services requesting the tokens. It would be cool if there was something to map the client ids to the names of the different services in the audit log.
Anyway, thanks for building this service. Like other's have already said, it's cool to see a useful dev-focused tool from within the community.
This is a very cool project, and I'm interested in using it for some of my private repos.
Some thoughts:
* Thanks for adding support for 2FA via OTPs, this is a requirement for me
* Access control is a little weird. I start without any users having access, but I can push to the repository. I can then add myself as "ro", and still push. I know this is an edge case but wanted to raise it
* I keep getting logged out while navigating through pages, though I'm guessing this is related to the 502's I'm getting occasionally (HN Effect)
>I keep getting logged out while navigating through pages, though I'm guessing this is related to the 502's I'm getting occasionally (HN Effect)
The 502's are a bug, rather than a scaling issue. git.sr.ht seems to have a memory leak, which I'm investigating. Are you logged out as you browse between different subdomains? There's a ticket for logging you into everything at once, but for now you have to click "login" on every sub-site.
It looks great and the minimalistic UI is a welcome breath :)
Could you share any details on how you implemented the build system? Are you running of different public cloud providers or are you using something different? Your announcement speaks about KVM so it looks like you implemented something yourself but I guess the cost and performance could easily become difficult to manage, so I'm curious how do you back this system :)
I built it all from scratch, and I host it on dedicated machines colocated in Philadelphia, with backup facilities in SF. It's pricy for the current scale, but as it scales will become very price effective.
This looks fantastic! One feature I would like to see in a service like this would be support for custom domains. Personally, I would be willing to pay extra for such a feature. It’s nice to have control of the domain for personal work, but self hosting for a handful of personal projects is a big ask - I would rather pay for someone to do it the right way.
Thanks for your feedback! This is definitely something I'm interested in adding in the future. I don't think I can prioritize it right now, because I have limited time to spend on sr.ht (I still have a day job), but I want to tackle it post-alpha.
Thanks for the response! I would definitely imagine a feature like this coming later on. Just signed up at $20/yr, and I hope everyone reading this does too... sr.ht is something that desperately needs to exist!
Drew, please keep doing phenomenal work.
Other stuff I'd love to see once sr.ht is more mature would be nice, clean, UNIX-ey alternatives to GitHub Pages and github.io. I'll be looking forward to OpenBSD support, especially for running CI jobs on as well.
Great, thanks for your support! I definitely intend to implement something similar to GitHub pages, but even more powerful - how about using any static site generator you want? OpenBSD support is also coming soon!
I was about to say the same. I'm able to login at meta but not the others. Admittedly I haven't paid yet so I thought that might have been the culprit.
This service looks promising, but it is unfortunate that we have to go as barebones as 'no javscript' to convince people that they are not doing any malicious tracking. Javascript is becoming inevitable and some service/company that helps us trust a site's javascript will be most welcome in the future.
Trying to register, and got a 403:
Forbidden
You don't have the permission to access the requested resource. It is either read-protected or not readable by the server.
I've always wished this to be open sourced. Oh man I'm glad there is no javascript nonsense, overall design is great. Thank you so much for opening this beauty :)
dispatch is the newest sr.ht service and docs are scant. They'll come eventually... but it's pretty similar to the rest of sr.ht, you could probably figure it out if you gave it a shot.
Yep! This is planned and partially working through builds.sr.ht. I deploy my blog, drewdevault.com, through builds.sr.ht: https://builds.sr.ht/~sircmpwn/drewdevault.com This is built with Jekyll and used to be on GitHub pages. The plan is to have a place where you can dump static content, then you can use any site generator you want with builds.sr.ht.
It's a memory leak in git.sr.ht, rather than an issue of scale, thankfully. I'm working on it. After a few refreshes you should get through, and the problem is isolated to git.sr.ht in particular.
>On top of that, sr.ht is one of the most lightweight websites on the internet, with the average page weighing less than 10 KiB, with no tracking and no JavaScript.
You mean more efficient, right? Because the single page "applications" that download UI and data with javascript take a three-digit number of requests and multiple seconds to render everything and be "done".
No, because once you download the js you don't redownload it on every page request. When you want to update contents you get the new data to be displayed. This is how any other gui application does server communication.
The traditional page based responses re-send all the html content over again. If the client can cache it then it doesn't have to be, but caching something like a git frontend does not work with page based responses due to the amount of new data.
Just because Facebook and Google abuse js to the nth degree does not mean it's automatically bad. It's how you use it, and you can infact do things without react and Vue.
As I just stated, you don't need to have 1MB of JS to do things, it's that software companies typically do it because they're about actually providing a service and solving problems than worrying about non-issues such as 1 second more of initial download time.
This is 2018. You don't have a 56K modem, I don't have one. Those that do will benefit from smaller data requests after the initial download. Holding back the real issues the web can solve over an arbitrary problem like that is damaging to what can be achieved.
The web is a software platform, and unless you want to equally complain about applications in C that go over 1MB, you're making mountains out of mole hills.
Are there any plans or ideas for a migration path from GitHub to sir.ht? I would imagine that if there was a way to transfer issues and discussions it would encourage more users to make the switch.
Here's one data point for you: zig programming language. Influencing factors:
* If we had syntax highlighting in the file browser, that would be a win over GitHub, which insists that there be "hundreds of GitHub repositories" before accepting a syntax highlighting pull request for a new language. I could imagine it would be reasonable to support "repository-local" highlighting configuration.
* Transferring existing content as mentioned above. It would be unwise for us to give up all the issues and discussion.
* The fact that the build service supports FreeBSD is already a win. However, to switch from Azure DevOps we would lose Windows builds. Is that ruled out due to the open source nature of sr.ht, or is that planned? Related, it would be attractive if sir.ht offered more architectures, e.g. i386, ARM, RISC-V (I believe this was mentioned but I could not find it in the docs)