Proposal for a non-JS, lightweight, cloud webapp: slcl

Development
1

Summary
slcl is a small and lightweight cloud solution that I personally wrote in C99 + POSIX. It aims to provide an efficient and simple alternative to Nextcloud that can run well on lower-end hardware, such as single-board computers:

Problem
After a few years self-hosting a Nextcloud instance on a Raspberry Pi 3B to store personal data, I became recurrently frustrated at its poor performance and high system requirements, both from client and server side, largely caused by Nextcloud being far from a simple solution to host my files, as well as choices in its design.

Solution
In lack of simpler alternatives that could run well on low-end hardware, I wrote my own software from scratch, called slcl (for “small and lightweight cloud”), in C99 + POSIX at the server side, with very few dependencies. At the client side, I also got rid of JavaScript, making use of plain old HTTP/1.1 “multipart/form-data” to upload files, as well as HTML5 features and some simple CSS.

This results in efficient, simple and reliable software that requires very few resources from the server, and loads fast on clients’ lower-end devices, such as the PinePhone.

slcl aims to provide similar features compared to Nextcloud’s “Files” app:

  • Private user directory
  • Configurable quota
  • Read-only public file sharing
  • Simple to configure, simple to use

slcl is free software licensed under the GNU Affero General Public License, version 3 or later.

Screenshots/Layouts

user

Alternatives

  • ownCloud: similar issues compared to Nextcloud
  • rsync: despite its simplistic design, slcl is meant also for non-technical users. rsync was unsuitable because it is a command-line application.
  • SeaFile: requires running JavaScript on the client side. slcl was meant for users that explicitly disable JavaScript on their web browsers for security or privacy reasons.
  • FTP: unfortunately, not supported by web browsers any more.
  • WebDAV: requires the use of specialized software. Again, one of the design goals for slcl was to be usable from a common web browser.

Tasks
I suggest the FreedomBox team to consider slcl as a new app into its toolchain, considering how both projects are meant to empower users with efficient, self-hosted software. Of course, contributions and improvements to slcl are welcome.

2 Likes
2

Thanks, this looks interesting.

Freedombox only relies on debian packages. Is there one for slcl?

EDIT: you made me notice that firefox removed support of ftp, apparently a while ago, which is a bit of a shock to me…

3

Unfortunately not. slcl is somewhat recent, and I have not contacted any packagers yet. Do you know how could I contact them?

4

I think we can make simpler. People who have a disabled JS should know how to use WebDAV or SFTP. If you want to share files with relatives or regular users then it should be ok to use a rich UI with JS. The NextCloud gives a rich UX with many plugins that looks familiar for users.

I’m working on YurtPage project were I want to turn usual WiFi routers that everybody already have into a cheap self hosting server.
This is already possible today with OpenWrt firmware and used by users. I just want to make it as an easy to install and use solution like the FreedomBox.

The NextCloud is too big for routers so I decided to use the WebDAV. Almost all web servers have a native plugin for it that works fast. The NC WebDAV works over a remote.php script so it simply can’t work that fast.
The Dav protocol is old and didn’t evolved for a long. Mailing lists are empty and people who made the spec are not working in this direction for decade(s?). There are many missing parts e.g. Delete a file to Trash bin, icon thumbnails, file permissions. So it’s difficult to adopt the Dav for both online document editing and files management. But we already have it today and it covers many needs.

Regular users won’t install dav programs but they need for a browser based solution or even a mobile app like Google Docs/Photos (which is already pre-installed on Android).

For this case I found a simple and perfect solution (you will not like it): put an index.html page with a small JS that will perform dav request and render UI. It’s called dom111/webdav-js and the index.hml looks like:

<link rel="stylesheet" href="https://cdn.jsdelivr.net/gh/dom111/webdav-js/assets/css/style-min.css"/>
<script src="https://cdn.jsdelivr.net/gh/dom111/webdav-js/src/webdav-min.js"></script>

And that’s it: a UI is ready.

Technically speaking you can also use the WebDAV and use <form method="PUT/DELETE" action="/dav/"> to upload/delete files directly. That’s a bad idea but still something that can be used.

Here is an example of dav share based on the Lighttpd which is used in many routers (Turris Omnia, Gl.iNet):

It has a very basic “admin panel” to configure an access. And it uses the same WebDAV protocol to change the Lighttpd config. That’s weird but works without any other software and you can run it out of the box on old Debian.
For the OpenWrt I’ll make a UCI configuration binding to make it easier to configure.
I liked the directory layout slcl and will try to adapt it for the openwrt-lighttpd-public.

This is great but still it would be great if the Dav become supported by browsers and the FTP was.

So my proposition is to make browsers to do this. Unlike FTP the dav support should be much easier.
At beginning I created a “WebDAV” browser extension. Internally it’s just adds the webdav-js when detects a dav share.
It’s unlikely that someone will install it because they ether already have a web UI or configured dav client. Maybe some lazy admins will use it.

Still I hope that users will test it and then we can go to a browser developers and ask to include it. Once the dav become supported by a browsers it will become much more used.
But it would be incredibly difficult, ok, impossible to add dav support into browsers. Even just show a prompt to a user to install a plugin/extension.

Another good news is that the dav:// protocol handler already works in Linux and opens a file manager (GNOME Nautilus and KDE Dolphin).

You can join our yurt-page chat in matrix.

5

Hello,

Sorry, I did not reply before because I don’t know. I just want to say that your code still looks interesting to me, I like that it is really small and since this is C (the main programming language I used when I was writing code), I should be able to read and understand it, so I will have some more look at it.

Meanwhile, one question: did you consider support of localization/internationalization?

6

I honestly find it hard to make it simpler than a single binary containing everything that is needed to run an instance, with no more dependencies than a POSIX-compliant C library, cJSON and OpenSSL.

As stated on the project README.md, I acknowledge there are better-suited tools for this purpose, such as rsync, SFTP or WebDAV. But those are tools most non-technical users are not likely to install themselves, who also include relatives and friends of mine. So being able to run slcl from a web browser without custom extensions was a requirement.

The whole reason why slcl was implemented is because Nextcloud is too large and slow for small servers, such as single-board computers like the Raspberry Pi 3, and it is also too large and slow for small clients, such as low-end smartphones like the PinePhone. Also, some users do not feel comfortable with JS for several reasons, and Nextcloud would not even start on a web browser without JS.

The design decisions behind slcl were made to provide a simple, lightweight, fast and useful experience to both servers and clients. And dropping JS from the start was need to fulfill these requirements.

To be honest, I do not find it fair to exclude users who do not want to use JS for very legit reasons.

If WebDAV and FTP were supported by web browsers, there would have been no need for slcl in the first place. But reality is sad, and I needed an easy and lightweight way to exchange files between peers who only have a web browser installed.

I already used KDE Dolphin when Nextcloud’s web-based UI was too slow. But then again, Nextcloud was still too slow to add/remove/rename files on my target hardware (a Raspberry Pi 3B).

Looks interesting! Although it looks more like a loose collection of useful software utilities rather than an integrated solution. Still, it is a nice read for users not familiar with self-hosting and the dangers from big tech.

7

Thank you! If that helps, Linux static binaries of slcl are also available from the official git repository, mentioned at the top post. These run without any dependencies other than the Linux kernel itself, so they can run on any Linux distribution out there. They should be definitely helpful for a quick start.

Interesting question. slcl has so few written text that IMHO it is not worth the effort into supporting localization, at least for now.

8

You raised an important topic. Let me break my thoughts:

  1. The NC is slow.
  2. The NC is bloated which makes uncomfortable for security reasons but also more difficult to administer.
  3. JS is required for NC which is bad for privacy.

1 Basically the NC is slow because it’s WebDAV implementation is written in PHP to support own extensions (thumbnails, trash bin).

Potentially we can revisit the WebDAV spec and add new features. Once web servers start to support the new features then the NC can switch and start working faster. There are many new WebDAV only sharing webservers that also already have some extensions and we can ask them to collaborate.

2 The NC bloat is perfectly solved by the slcl. Personally I would rather use some CGI-BIN based solution. I have an additional limitations in size so will use the web server like BusyBox httpd. From security perspective this also has some advantage because I know that the HTTP server part was better reviewed.

3 I just want to add that generally speaking the JS by itself is harmless but it’s browsers who allow trackers to use the JS tricks. Also unexpectedly if you have a JS disabled then this is even easier to fingerprint you. So this may be like a snake oil. Ideally we need more general solution like independent community driven browser (the Mozilla is 99% funded by Google), network level tunnels like Tor/p2p mashes. Or even demand for legal solutions like GDPR.
More deeply the problem is that most web sites doesn’t have other revenue channel expect of online ad (and selling data). So many researches end up with developing a some payment systems built in to a browser (e.g. BraveBrowser BAT tokens, LBRY/Odysee).

The slcl is a great tool to solve user problems today.
It would be great if you can add the slcl to the “Awesome Selfhosted” list.

If we can collaborate somehow to make the WebDAV supported by the browsers (at least by FF) that would be great. For now I didn’t even created a feature request to FF bug tracker and decided to working on this later. Given that the FF team is always busy we need to prepare a PR for them.

9

@xavi I tried running this locally on Debian 12 using the static amd64 build from Gitea.

I couldn’t get past the step of logging in. The application doesn’t accept any of the users I create using the script usergen.

10

@njoseph Some time after the 0.1.0 release, I realised there was a bug on usergen that would cause issues with longer passwords, and was eventually fixed by this commit.

I have just released slcl 0.2.0 with the bugfix above, as well as some other fixes and improvements. Static Linux binaries are already available for x86 and x86_64.