Solid is a revolutionary technology created by the inventor of the Web, Sir Tim Berners-Lee. It is a combination of standards and protocols that enable decentralization of the web as it exists today. Solid empowers individual entities (people, organizations, teams, etc.) to separate their data from the systems and applications that leverage it through the use of personal online datastores (pods).
Our goal is to provide developers with a robust toolkit that allows them to develop high-quality applications on Solid, without a ton of prior knowledge or expertise with decentralization or linked data.
We believe that providing developers with a great foundation to build awesome apps will help to establish best practices for development on Solid, and lead to some quality results that bring new users into the ecosystem.
We decided to start with React based on its relative popularity in the Solid developer community, but we plan on creating kits for other major frameworks very soon.
We use this SDK ourselves, and will continue to expand and improve upon it as we apply it to real-world use cases.
The React SDK for Solid is a combination of libraries, components, documentation, best practices, and an application generator meant to accelerate the development of high-quality Solid applications. The Release Timeline identifies when a given listed item will be available.
In summary:
- Reusable Components that you can use on your own in the applications that you build
- An Application Generator that incorporates all of the components and best practices together for you, standing up a fully functional Solid React application.
- Best practice patterns that you can reference as examples of how to accomplish particular things
More specifically:
- Application Generator
- User Registration
- User Authentication
- Test Infrastructure
- Error Handling
- Design System
- Linked Data Javascript API
- User Profile
- Internationalization (i18n)
- User Preferences
- Notifications
- Accessibility
- Access Control
- Linking Things
- Data Discovery
https://github.com/Inrupt-inc/generator-solid-react
Since most developers are entering the Solid ecosystem for the first time, we felt it was crucial to give them the ability to get something stood up quickly that they could use as the basis for a quality React application - fast. And so we've put together a yeoman generator that combines all of the components and best practices in the SDK into something you can use to get going, or as a reference.
https://github.com/Inrupt-inc/solid-react-components
User Registration is a bit different in a decentralized Solid world. "Registration" in the Solid ecosystem means having a Pod and a corresponding WebID. When a user doesn't have these and wants to use a Solid application, the application will need to help them register a new pod without losing the user in the shuffle. We provide componentry and an intuitive UX to facilitate this.
https://github.com/Inrupt-inc/solid-react-components
User Authentication in Solid uses OpenID Connect (OIDC) with WebID to provide fully decentralized cross-domain authentication. We provide componentry to facilitate the complete login / logout workflows, leveraging solid-auth-client.
Check out the WebID-OIDC Spec for additional background.
We believe that robust testing is essential to quality applications, and our aim is to have as complete coverage as possible. We use a combination of Enzyme and Jest, as we find that the two are quite complementary. Any release with new functionality, or updates to fix non-trivial bugs, will be accompanied by new or updated tests.
Comprehensive Error Handling helps users and developers diagnose and respond to issues as they arise. Our goal is to have every error in the SDK captured and displayed in a friendly and informative manner, providing as much relevant information as we can.
Our set of component libraries will own their own error messages, and bubble them up to the parent application. Running the application generator will provide reference examples of how component error messages can be consumed and displayed to the user across several common cases, including in-line form validation errors, UI display errors, and server-generated error codes.
https://design.inrupt.com
Inrupt's atomic design system is a pattern library of user interface elements that can be utilized in Solid applications. It follows Brad Frost’s Atomic Design principles (http://atomicdesign.bradfrost.com/), and incorporates the Block, Element, Modifier Methodology (or BEM: https://en.bem.info/methodology/), for building systematic, coherent design systems. These patterns can be utilized as-is in their current state, or customized as needed. The Application Generator will automatically incorporate the design system into the code it generates.
One of the most unique aspects to developing on Solid is the underlying linked data model. It is also what makes Solid so powerful. For a brief primer, check out our Introduction to Linked Data.
Perhaps the greatest barrier to broad developer adoption of linked data has been the lack of intuitive utilities to query and manipulate it. While there are extremely powerful libraries to interface with the RDF (Resource Description Framework - the model that drives linked data), these require a lot of prior knowledge about RDF and tend to be hard to wield out of the gate by the average developer, which can lead to abandonment.
Ruben Verborgh lays this out well in this post, and introduces the tooling that we've been excited to incorporate into the SDK - https://github.com/RubenVerborgh/LDflex. We'll be using LDFlex throughout our components and generated code. However, we will also provide some examples of using a powerful lower level RDF library - rdflib.js - for reference.
Nearly all applications will need to allow users to manage a user's profile information, and so we provide a component to facilitate this. It's also a great reference for working with linked data forms to read and write linked data.
Solid is a decentralized worldwide movement, with the ability for applications and data to interface across borders and cultures. As such, it is important to have robust internationalization support from the start. As many developers know, i18n is something that is fairly painless to incorporate when you start making something, and quite a pain to do after the fact. We provide code and demonstrate best practices for internationalization in a linked data Solid world.
The applications most of us use today manage user application preferences. In Solid, user preferences are a bit different (and more powerful), because Solid decouples an application from the data model and corresponding entities ("things") that it depends on. As a result, while a user may manage some preferences that are very specific to the application they're using, they are just as likely to manage preferences associated with the "thing".
For example, consider a chat room. A chat room is a "thing" in linked data. Different people can use different chat apps to message each other in that chat room, because they speak the same vocabulary. That chat room can have a preference associated with it that automatically expands images inline. Regardless of what chat app you're using, your images will be expanded in that room. Similarly, Alice may have a preference associated with any instance of a "chat room" (regardless of the application) that suppresses inline image expansion. We provide the facilities to manage this cleanly.
Solid has a lightweight and versatile mechanism for notifications that work across applications and systems via Linked Data Notifications.
Linked Data Notifications (LDN) supports sharing and reuse of notifications across applications, regardless of how they were generated. This allows for more modular systems, which decouple data storage from the applications which display or otherwise make use of the data. The protocol is intended to allow senders, receivers and consumers of notifications, which are independently implemented and run on different technology stacks, to seamlessly work together, contributing to decentralisation of our interactions on the Web.
Authorized agents can write messages to pods, and applications can determine which message types they are interested in subscribing to. We provide componentry to read and write notification messaages, with the ability to receive message in real-time via websockets.
Accessibility is important to us. We believe and hope that the SDK is used to create inclusive applications that work for everyone. We have done our best to incorporate accessibility best practices throughout our code as outlined by Mozilla for HTML, CSS & Javascript. That said, we fully expect that there will be areas missed, either now or in the future. If you come across any, please let us know, or even better - fix it and submit a pull request!
Solid determines what agents are able to access resources in a pod through Web Access Control (WAC).
Web Access Control (WAC) is a decentralized cross-domain access control system. The main concepts should be familiar to developers, as they are similar to access control schemes used in many file systems. It's concerned with giving access to agents (users, groups and more) to perform various kinds of operations (read, write, append, etc) on resources.
Any application that is reading and writing linked data to a pod will need to manage permissions for some of that data eventually. We include helpers and componentry for reading and writing WAC statements pertaining to individual agents and/or groups.
Leveraging the aforementioned Linked Data Javascript API, we provide code and ui that shows developers how to link different things together. In linked data, you can link any "Thing" to any "Thing". It's crucial for developers to internalize that, and so we do our best to illustrate how that's done through example.
Data discovery is the key to interoperability. Applications need to know where to find a particular kind of data, and similarly, where to put it. Different users will have different preferences based on how they organize the data in their pod. We will provide a means to solve this problem an a universal way that is not implementation specific through linked data shapes.
We follow an iterative release pattern, and will have scheduled releases every two weeks. Releases may include new components, as well as improvements or fixes to existing ones.
| Date of Release (2019) | Targeted for Release | Notes |
|---|---|---|
| January 30th ✅ | Application Generator, User Authentication, User Registration, Design System, Accessibility, Test Infrastructure, Error Handling | Initial release focused on standing up the core infrastructure of the SDK and Application Generator. Components in subsequent releases will be incorporated into the generator as part of that release. |
| February 13th | Linked Data Javascript API, User Profile | Reading and writing Linked Data associated with a User Profile using LDFlex, as well as other examples of how to read and write Linked Data with Forms. |
| February 27th | Internationalization, User Preferences | Weaving in i18n and Preferences. |
| March 13th | Notifications | Reading and writing notifications, with real-time support over websockets. |
| March 27th | Access Control | Helpers and componentry for reading and writing WAC statements |
| April 10th | Linking Things, Data Discovery | An approach for universal data discovery, and intuitive examples of how to create a linked data graph for use in your applications. |
Feedback is essential and much appreciated. If you have a problem, an idea, or anything in between, open an issue to let us know! A member of the project team will follow up.
We aim to support the latest stable version of each major browser on desktop, mobile, and tablet.
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent