Migrating from NSS to CSS

Back in 2014 a group of people along with Sir Tim Berners Lee began implementing an early Solid server written for Node.js and called it Node Solid Server (NSS). For a number of years this was the main Solid server used in the community and many people contributed to its development and maintenance.

In 2021 a new open source Solid server was written for Node.js and this was called the Community Solid Server (CSS). The Solid specifications have progressed significantly since the early days when NSS was created as a prototype so the goal for CSS was to provide an open source server that:

  • Conformed to the specification
  • Is modular and enables researchers to experiment
  • Is easier to maintain

CSS was initially completed in August 2021. Since then it has been used by a number of people and continues to be maintained so that it can conform with the Solid specifications. At the moment, there are a number of Solid services in the Community that are hosted using NSS. In order to give the Community access to the latest capabilities in the spec and ensure they are writing spec compliant applications, it is important that these services migrate from NSS to CSS.

CSS is compatible with the NSS file format so the primary migration effort involves user accounts and the identity provider. For people operating Solid services with a small number of users the migration is straightforward as they can collaborate directly with their users. However, for those operating a Solid Service with a significant number of users, a migration will be more involved.

Inrupt would like to help those who would like to migrate to CSS so we are offering a grant of USD 10,000 to anybody with knowledge of NSS user accounts who would like to provide an automated migration system for the rest of the community.

Requirements

  • The deliverables must be open source and use the MIT license.
  • All data and associated authorization ACL files must be migrated while protecting privacy
  • All active user accounts must be migrated
  • Migrated users must either
    • be able to use the same password (Additions to CSS password handling)
    • OR, receive an email with a password reset link (must have the email address already)

Active accounts are defined as those where the user has logged in within the past X days where X can be defined by the person doing the migration.

Deliverables

  • The software required to migrate an NSS instance to a CSS instance
  • A set of tests that prove the migration works
  • Instructions to guide a service provider through a migration.

Application process

Applicants should send a simple email to NSS-Migration-Grant@inrupt.com.

Please describe any experience you have with

  • NSS and/or CSS
  • NSS account storage
  • NSS password encryption
6 Likes

I’d honestly be very surprised if you can find someone willing to do this for only $10,000 – whilst that’s a lot of money, both you and I know that at freelancer rates, it’s maybe a month or two of income, whilst this project will likely require many months of work.

There’s likely no way to migrate everything easily whilst “protecting privacy” – the software will have to touch people’s data in order to migrate it, unless you some how manage to do it all in browser, but that has it’s own risks attached.

Good luck to whoever attempts to take you up on this.

I personally don’t have time for this project, but I’m curious if there are some resources about how to migrate from one CSS to another CSS, (or NSS to NSS) that happened in the browser (for privacy), does it exist?

The project is to migrate NSS to CSS keeping the same server domain and data filesystem.

I think it can only be done on server side by a server admin and you must trust the server admin. This is already the case. NSS and CSS do not encode data, except the password.

The issue is not with the pods data that is identical (except the pod root folder name), but with the IDP part.

The general idea is

  • to list all NSS pods: pod name/email/NSS encoded password

  • Then create a CSS server with a batch process : pod owner/email/new CSS password

  • copy/move the data in the CSS server

  • Send the CSS password to the email owner

The process could be a bit more complex when NSS pod have no email.
An idea would be to create a CSS virtuel email and create an NSS migration server where an owner can login in with his NSS password and be given in return CSS email/CSS password. The issue here is to delete the CSS password on the NSS migration server.

Nota : things may be more secure if both NSS and CSS where encoding password with the same algorithm.