
* feat: implemented SizeReporter and FileSizeReporter * test: FileSizeReporter tests * feat: added QuotedDataAccessor * test: added extra test to check recursiveness of filesizereporter * feat: added QuotaStrategy interface * feat: further progress in different files * feat: wrote doc, tests and improved code * feat: fixed bugs and code is now runnable and buildable * feat: finished implementation * fix: revert accidental chanegs * fix: fileSizeReported did not count container size * fix: bug calculating container sizes fixed * test: FileSizeReporter tests * test: QuotaDataValidator tests * test: QuotaError tests * fix: removed console.log * doc: added doc to several files * doc: changed doc for QuotaStrategy to new implementation * fix: improved content length regex * feat: improved GlobalQuotaStrategy code * fix: made FileSizeReported readonly * feat: added comments to quota-file.json * fix: changed default tempFilePath variable * test: included new tempFilePath variable in testing * chore: created seperate command for start:file:quota to pass tests * feat: removed all sync fs calls from FileSizeReporter * feat: minor changes in multple files * fix: changed function signatures to be in line with others * feat: optimized quota data validation * feat: improved FileSizeReporter code * fix: corrected calculation of containersizes and fixed erroring edgecase * feat: save content-length as number in metadata * feat: added comments and changed GlobalQuotaStrategy constructor * feat: changed file names and added small comment * test: AtomicFileDataAccessor tests * test: completed FileSizeReporter tests * fix: content-length is now saved correctly in RepresentationMetadata * feat: adapted content length metadata + tests * fix: removed tempFilePath variable * fix: reverted .gitignore * fix: forgot to remove tempFilePath variable from componentsjs config * test: GlobalQuotaStrategy tests * feat: replaced DataValidator with Validator * feat: reworked DataValidator * feat: added calcultateChunkSize() to SizeReporter * test: updated FileSizeReporter tests * fix: tempFile location now relative to rootFilePath * test: QuotaDataValidator tests * fix: corrected FileSizeReporter tests * fix: adapted FileSizeReporter tests * fix: FileSizeReporter bug on Windows * fix: regex linting error * feat: changed Validator class * feat: added PodQuotaStrategy to enable suota on a per pod basis * chore: bump context versions * fix: Capitalized comments in json file * chore: renamed ValidatorArgs to ValidatorInput * chore: order all exports * fix: made TODO comment clearer * chore: added seperated config files for global and pod based quota + fixed comments * chore: made minor changes to comments * feat: added PassthroughDataAccessor * feat: added PasstroughtDataAccessor + tests * fix: added invalid header check to ContentLengthParser * chore: improved mocks * chore: move quota limit higher up in config * fix: atomicity issue in AtomicFileDataAccessor * chore: moved .internal folder to config from FileSizeReporter * fix: improved algorithm to ignore folders while calculating file size in FileSizeReporter * fix: changes to support containers in the future * fix: added error handling to prevent reading of unexistent files * feat: added generic type to SizeReporter to calculate chunk sizes * test: use mocked DataAccessor * chore: added some comments to test and made minor improvement * fix: fs mock rename * chore: QuotaStrategy.estimateSize refactor * chore: move trackAvailableSpace to abstract class QuotaStrategy * fix: improved test case * test: quota integration tests * chore: edited some comments * chore: change lstat to stat * feat: moved estimateSize to SizeReporter to be consistent with calcultateChunkSize * test: finish up tests to reach coverage * fix: basic config * fix: minor changes to test CI run * fix: small fix for windows * fix: improved writing to file * chore: linting errors * chore: rename trackAvailableSpace * test: improved integration tests * test: logging info for test debugging * test: extra logging for debugging * test: logging for debugging * test: logging for debugging * test: logging for debugging * test: improved Quota integration test setup * test: improve quota tests for CI run * test: debugging Quota test * test: uncommented global quota test * test: changed global quota parameters * test: logging for debugging * test: logging cleanup * chore: minor changes, mostly typo fixes * chore: remove console.log * fix: getting inconsistent results * chore: try fix index.ts CI error * chore: try fix CI error * chore: try fix CI error * chore: revert last commits * chore: fix inconsistent files with origin * test: minor test improvements * chore: minor refactors and improvements * fix: added extra try catch for breaking bug * chore: improve config * chore: minor code improvements * test: use mockFs * feat: add extra check in podQuotaStrategy * chore: replace handle by handleSafe in ValidatingDataAccessor * chore: typo * test: improved Quota integration tests * test: made comment in test more correct * fix: rm -> rmdir for backwards compatibility * fix: fsPromises issue * chore: leave out irrelevant config * chore: removed start script from package.json * fix: Small fixes Co-authored-by: Joachim Van Herwegen <joachimvh@gmail.com>
Community Solid Server
The Community Solid Server is open software that provides you with a Solid Pod and identity. This Pod acts as your own personal storage space so you can share data with people and Solid applications.
As an open and modular implementation of the Solid specifications, the Community Solid Server is a great companion:
-
🧑🏽 for people who want to try out having their own Pod
-
👨🏿💻 for developers who want to create and test Solid apps
-
👩🏻🔬 for researchers who want to design new features for Solid
And, of course, for many others who like to experience Solid.
You can install the software locally or on your server and get started with Solid immediately.
⚡ Running the server
To run the server, you will need Node.js.
We support versions 12.7 and up.
If you do not use Node.js,
you can run a Docker version instead.
💻 Installing and running locally
After installing Node.js, install the latest server version from the npm package repository:
npm install -g @solid/community-server
To run the server with in-memory storage, use:
community-solid-server # add parameters if needed
To run the server with your current folder as storage, use:
community-solid-server -c @css:config/file.json
📃 Installing and running from source
If you rather prefer to run the latest source code version, or if you want to try a specific branch of the code, you can use:
git clone https://github.com/solid/community-server.git
cd community-server
npm ci
npm start -- # add parameters if needed
📦 Running via Docker
Docker allows you to run the server without having Node.js installed:
git clone https://github.com/solid/community-server.git
cd community-server
# Build the Docker image
docker build --rm -f Dockerfile -t css:latest .
# Run the image, serving your `~/Solid` directory on `http://localhost:3000`
docker run --rm -v ~/Solid:/data -p 3000:3000 -it css:latest
# Or use one of the built-in configurations
docker run --rm -p 3000:3000 -it css:latest -c config/default.json
# Or use your own configuration mapped to the right directory
docker run --rm -v ~/solid-config:/config -p 3000:3000 -it css:latest -c /config/my-config.json
🔧 Configuring the server
The Community Solid Server is designed to be flexible such that people can easily run different configurations. This is useful for customizing the server with plugins, testing applications in different setups, or developing new parts for the server without needing to change its base code.
⏱️ Parameters
An easy way to customize the server is by passing parameters to the server command. These parameters give you direct access to some commonly used settings:
parameter name | default value | description |
---|---|---|
--port, -p |
3000 |
The TCP port on which the server runs. |
--baseUrl. -b |
http://localhost:$PORT/ |
The public URL of your server. |
--loggingLevel, -l |
info |
The detail level of logging; useful for debugging problems. |
--config, -c |
@css:config/default.json |
The configuration for the server. The default only stores data in memory; to persist to your filesystem, use @css:config/file.json |
--rootFilePath, -f |
./ |
Root folder of the server, when using a file-based configuration. |
--sparqlEndpoint, -s |
URL of the SPARQL endpoint, when using a quadstore-based configuration. | |
--showStackTrace, -t |
false | Enables detailed logging on error pages. |
--podConfigJson |
./pod-config.json |
Path to the file that keeps track of dynamic Pod configurations. |
--mainModulePath, -m |
Path from where Components.js will start its lookup when initializing configurations. |
🧶 Custom configurations
More substantial changes to server behavior can be achieved by writing new configuration files in JSON-LD. The Community Solid Server uses Components.js to specify how modules and components need to be wired together at runtime.
Examples and guidance on configurations
are available in the config
folder.
Recipes for configuring the server can be found at solid/community-server-recipes.
👩🏽💻 Developing server code
The server allows writing and plugging in custom modules without altering its base source code.
The 📗 API documentation and the 📐 architectural diagram can help you find your way.
If you want to help out with server development, have a look at the 📓 developer notes and 🛠️ good first issues.
📜 License
The Solid Community Server code is copyrighted by Inrupt Inc. and imec and available under the MIT License.
Core contributors are Joachim Van Herwegen, Ruben Verborgh, Ruben Taelman, and Matthieu Bosquet.
🎤 Feedback and questions
Don't hesitate to start a discussion or report a bug.
Learn more about Solid at solidproject.org.