Allow panes to be added dynamically

[megoth]

By allowing panes to be added dynamically (instead of bundled with the data browser, which it is today) we should fix a couple of problems with the current data browser. It would introduce a couple of other features, such as auto-updates that are not dependent on pod providers updating the data browser.

This feature may allow panes to be added from external sources, which adds certain security concerns. To counter some of these problems we want to require panes to expose themselves with a RDF data model that requires the developer or service provider to sign it. This should make it easier for organizations that wants to verify the security of these panes and provide a service that helps the user to be certain of the security of the pane.

We believe users will enjoy the possibility of adding panes dynamically through some sort of installing mechanism, for example by browsing an online store. This possibility adds a lot of other concerns, such as privacy (should these external panes ask for permission to resources as other applications would, or would they be inherently trusted, as the other default panes are), security (how can users be sure that a provider of a pane is not malicious), and more.

This feature could also be extended with a commercial dimension, where users buy services that are delivered partially or fully by panes. This extension comes with its own slew of challenges, such as how to prevent piracy, how to handle the transaction of payment itself, and more. Some of these concerns lie outside the scope of the data browser, but work should start on how to tackle those concerns that data browser can help solve.

Action items

• Decide how "open" this should be - should the user be able to add panes from all over the web, or be limited to a list that the Pod provider controls?
  • As a first step it might be easiest to limit it to the latter first, and then expand the scope once we have a better understanding of how this module system will work
• Introduce a vocabulary for Solid panes so that they can be described with RDF
• Extend the current panes registry to allow adding panes dynamically
• Port existing panes to use this mechanism, so that they can be auto-updated by default
• Start work on how mechanisms can be implemented to prevent piracy

[megoth]

I just had a talk with @timbl, and we decided to postpone this work a bit until we have a better code base and UX for the current panes. That should also give us a bit more insight into the various panes to understand the challenges that loading them dynamically will introduce.

[Vinnl]

Posting this earlier overview I wrote for posterity:

When it comes to dynamic Panes, there are different options with different levels of dynamism. The level of dynamism we want dictates what approaches are possible, so to decide on that first, here's a preliminary overview of a few different approaches with their pros and cons.

User links to Panes

In this approach, users could themselves insert a link to a (Turtle file point to a) Javascript file containing a Pane definition.

Pros

• The user can pick any Pane they want
• Commercial Panes can be sold to individual users

Cons

• The user has to make sure that the Pane is compatible with the version of the data browser running on their Pod, or risk it breaking.
• This could be a security risk: the script can do anything the user can. (Then again, I guess any Pane can, given that they are given full access to the user's Pod? Still, the user might not be best suited to vet third-party Panes.)
• Either the user is unlikely to ever install updates to the Pane, or the Pane provider automatically pushes the latest version, always - which can be problematic with e.g. data migrations, or changes of ownership.
• Panes have to register themselves through the global scope, opening up another source of bugs that are difficult to track down and solve.

The Pod admin links to Panes

In this approach, the Pod admin adds links to Javascript files hosted at third-party servers containing a Pane definition.

Pros

• Pane licenses can be sold to enterprises as a whole

Cons

• Users are dependent on Pod admins adding support for a Pane.
• Either the Pod admin has no control over the third-party code (security risk), or has to manually check for and apply updates.
• Panes have to register themselves through the global scope, opening up another source of bugs.
• We will have to provide our own package manager, doing work that busies entire companies in other ecosystems.

The Pod admin installs Panes through a common package manager

In this approach, the Pod admin can e.g. npm install some-pane to make it available to Pod users.

Pros

• Pane licenses can be sold to enterprises as a whole
• Panes do not need to register themselves through the global scope, saving a lot of ceremony and potential bugs
• Proper package management makes it a lot easier to track and install (security updates)

Cons

• Users are dependent on Pod admins adding support for a Pane

Those lists are not exhaustive or definitive.

[PSFW]

This is something I am struggling with at the moment, I want to create a user-defined form that will sit inside of a pane for a user-defined type. I don't see how this is possible at the moment (besides the mentioned hack here - SolidOS/pane-registry#28 )

[bourgeoa]

Could you give a bit more details on your project.

I don't know if it will be of any help but you may look at meeting-pane or issue-pane they both have a shortChat pane that can be embedded.

[PSFW]

Hey @bourgeoa, thank you for getting back to me, I sure can.
I have created a basic ontology to hold personal measurements (i.e. for working out clothes sizing), this ontology also holds a SHACL shape. This is not an ontology that is known to Solid Namespace so I recognise this may be a problem too.
Now that I have my ontology with it's defined Shape, I would like to be able to input data into my pod with it. I would like to create a user-defined Pane that does not exist within the panes library but is loaded into the pane registry all the same (via some mechanism, and this pane is possibly hosted within the Pod itself).

This Pane would contain a Solid UI form that allows the user to input data in the specified Shape to the Solid Pod.

[josephguillaume]

I want to create a user-defined form that will sit inside of a pane for a user-defined

Very belatedly, the form pane sounds like it already meets this need. If there's a triple :subject ui:annotationForm :form, then the form pane is enabled and displays :form with the data for :subject.

The form pane requires the form to be defined with the UI ontology
https://solidos.github.io/solid-ui/Documentation/forms-intro.html

:form can be in another document if there is a :subject rdf:seeAlso :form to tell the databrowser to load that document.

[PSFW]

Thank you very much I appreciate the reply, I will see what I can do with this information

…

On Mon, 10 Jul 2023, 13:58 Joseph Guillaume, ***@***.***> wrote: I want to create a user-defined form that will sit inside of a pane for a user-defined Very belatedly, the form pane sounds like it already meets this need. If there's a triple :subject ui:annotationForm :form, then the form pane is enabled and displays :form with the data for :subject. The form pane requires the form to be defined with the UI ontology https://solidos.github.io/solid-ui/Documentation/forms-intro.html :form can be in another document if there is a :subject rdf:seeAlso :form to tell the databrowser to load that document. — Reply to this email directly, view it on GitHub <#103 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AKTDRBA2NSP7DOXFWOUBA6TXPP355ANCNFSM4HQE654Q> . You are receiving this because you commented.Message ID: ***@***.***>