Migrating from NSS to CSS

1

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
2

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.

1 Like
3

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?

4

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.

5

I agree with the move, but only if we use a open commmunity fork of the CSS code and not the one that is maintained by the UGhent/imec team.

The reason we created the open fork at the time was that bug reports in the UGhent/imec-controlled issue tracker were being vandalised. (!)

That was a while ago, but this morning I was chatting with Joachim van Herwegen about making some substantial contributions to the CSS project, and shortly after I received the following email from a different member of the UGhent/imec team (not Joachim himself):

Michiel,
I repeat: please leave our employees alone.
I am […], and we certainly don’t have to spend time contacting you.
That decision is final, so you can stop doing it.

The reason we don’t interact with you is because 1) you don’t have the necessary technical competencies, and 2) you’re just out to steal people’s time to put yourself in the spotlight. The entire community has already lost months of work on interactions with you, and we as Ghent University/imec will no longer go along with that.

You are the stereotype of an attention-addicted narcissist, which is why [we] need to protect [our] employees from wasting our precious time.
Go steal other people’s time, you will get more applause and spotlights there. But not from us. Jamais.

(“Jamais” is French for “never”).

It is therefore, I think, clear that the way this team interacts with the rest of our community is unacceptable, and the governance of this code repository is not in line with the spirit of open source software development that we want solidcommunity.net to be associated with.

After years in the Solid community I and others have gotten used to the bullying, but that doesn’t make it OK. Let’s stick to our spirit of open collaboration and friendly manners.

So by all means, please produce the migration script that Inrupt generously offered to sponsor, but let’s make sure we migrate solidcommunity.net to an inclusive community fork of CSS, governed in an open and inclusive way, so that everybody who is enthusiastic about Solid is welcome to contribute as they can.

2 Likes
6

@michielbdejong if youve been asked repeatedly to leave them alone, you dont seem keen on following that? Sounds like a problem right there. Knowing when to stop is needed. There seems to be a part of the story missing of how you got asked to stop. You are one of 45 contributors to the CSS => Contributors to CommunitySolidServer/CommunitySolidServer · GitHub and they didnt say no to them, your personal fork seems to have less => Contributors to pdsinterop/community-server · GitHub, seems like the open community fork is just really yours? was there a disagreement? Not judging here, but stop means stop. We’re all big on consent here.

rather than involving the < rest of the community > in a conclusion, you could perhaps just sit together in a room and work this out? I get that you are a voice of the community, but we all have flaws. nobody wins with throwing half stories on the internet for karma points, we all loose when this is what you do. Forks dont solve people problems, never have, never will.

all im saying is, talk this out with people.

7

Actually, forks do solve people problems, by removing the problematic people from the equation. A famous example of this is the Node.js project for to IOJS, which ultimately superseded & replaced the node.js project, once those that had been problematic to open development had moved on to other things (because they were no longer getting free labour from contributors)

And just going by the name & creation date of your account, @solid-curious, you’re either deliberately posting on a burner account, or you’re unaware of the historical context around this matter, which I’d suggest you go learn before suggesting everyone just “sit together in a room and work this out”

The people in the wrong here have repeatedly acted like this towards many many community members, even driving some away, or at least contributing to an unhealthy environment which drove them away.

5 Likes
8

@ThisIsMissEm well indeed we dont know the history and that is the point. We have @michielbdejong showing people asked him to not contact, then showing us that he crossed their border, and then crosses it on this forum with tagging people form that did not want contact. looks like a border issue to me, people react strongly when you go to far many times. there is a lot of history missing here, and perhaps you know it, if I had to guess Id say a business proposal was made and rejected and kept on insisting. if you know the history thats great but its not complete for us, and actually i dont think we need to know, just not the right way to make decisions on half stories. we know from @ michielbdejong own post that he crosses borders, is rejected, but nothing about anyone else not being participated (I count 45 committers). seems early for a call for a personal fork based on one person.

I think that the io.js project has manyd evelopers behind it, is that correct? I read a claim about the < open community fork > but i went to have a look and there is no history there, its a personal fork from one year ago with 5 commits by @ michielbdejong.

but yes i still beleive getting in a room is the right solution, people online are keyboard warriors but being together forces them to talk things out, also i dont want to know people’s drama, I am here for the code

9

No, this is gaslighting. You may not know the history, but I’ve certainly been around in the community long enough to know it, as do many others.

It is clear that you’re not just “some random person curious in solid” but instead someone who is trying to abusively use a burner account to try to rewrite the story & manipulate the conversation at hand.

I definitely encourage you to give the Solid code of conduct a read, and think about your actions and the way you choose to interact with the community.

6 Likes
10

@ThisIsMissEm I dont think its fair that were talking around other peoples intentions here, if you know the history of why people are asking for no contact

@michielbdejong Could you tell why you are contacting people against their wishes and tagging them here despite a clear ask for no contact ? what can we as a community do to help?

11

Hi @solid-curious,

Thank you for raising your concerns, you’re asking some good questions! It’s totally OK that you choose to do so anonymously.

I don’t think I tagged anyone in my post, actually? In any case I did my best to anonymise the email I quoted.

I understand your first reaction might be that probably I must have done something to deserve to be treated this way by the UGhent/imec team. I can assure you that this is not the case. Also, that’s also not the topic of this forum issue.

The problem is we got to a point where they clearly state they no longer want to collaborate with (some of) us, or at least not in the open and welcoming way that our code of conduct expects from all Solid project participants.

I do understand that seeking consensus and collaborating in an open way can sometimes be hard and frustrating. Sometimes it may feel like everybody else just “doesn’t get it”, and is just wasting your time. But whenever we feel that way, there is usually a reason for why the other people in a discussion take a standpoint that is surprising to you. This happens everywhere in the software and web standards world. So I also don’t blame them if they want to take their software project in its own direction. Then it stops being “our community server”, and it will just be theirs, to develop as they see fit.

But it is enriching to overcome this feeling and learn why other people have different opinions, and it’s beautiful to see how sometimes many people can come together voluntarily in a single project and build something amazing. That is what we’re trying to do in the Solid project, and that is the spirit we want to protect.

Both because we believe that consensus is the only way to come to an open standard together, and because we want to have fun and work in an environment where we can all be ourselves and write GitHub issues without fear of being shouted at or of our work being deleted or marked off-topic by a fellow community member who takes a different viewpoint.

Now to the point of which CSS fork we should run on solidcommunity.net:

One of the nice things about Solid is that it gives us choice. In this case, for the server we as a community collectively maintain, use, and experiment on, we have a free choice of which implementation of Solid we want to run there. There are six different ones! See https://solidservers.org That’s also what makes the Solid spec and test suite so important, and what makes this migration from NSS to CSS possible in the first place! :slight_smile:

As Solid community members, we all want to have the option to influence how the code on this server behaves. And when we want to suggest a feature request in the GitHub issue tracker of the software that runs there, we don’t want to be met with hostility. So that’s why I think it’s clear by now that the mainline CSS repo is not an option for this.

I do share your hope that the forks of CSS will one day merge back together - until then, there will just be “mainline CSS” and one or more community forks side by side. We can then discuss the feature requests and bugfixes for the software for our community server in a separate repo, while respecting the wish of the UGhent/imec team to be left alone.

1 Like
13

While issues brought up here are important, they are not on topic for this posting. We are therefore locking this conversation. The issue of which CSS version to use in the migration is on the Solid Team’s agenda. Context-based feedback is welcome, but please, with less heat. Thanks!

4 Likes