# What do Developers Think the Solid Ecosystem Needs?
# https://shorturl.at/uBG07
## Resource to Find Vocabularies/Shapes for a specific Domain
- Actual Data samples. Not dummy data samples
- https://pdsinterop.org/conventions/overview
## Files vs Triple stores
- Files are a in between step.
- Nothing is stopping having a different format on your solid server.
- You should write apps that are not specifically solid apps, but apps where you bring your own storage
- Optimally, as a developer, we shouldn't need to care that things are in multiple files.
- Solid should be abstracted away from Web developers. We should have a middleware library that abstracts that.
- You should have a single endpoint that you can trigger.
- This needs to be handled as a middleware.
- People want a Sparql query
### Arguments against treating the Pod as a database rather than a file store
- Tim's Argument for Document Store: It puts data at URLs and Databases don't. Putting data at URLs makes the Web of Data
- Indexing can be built as middleware rather than being built on the server itself.
- It accelerates atomization based on the server. The boundary of the server should be entirely invisible.
### Arguments for treating the Pod as a database rather than a file store
- file store and document store let the app decide on how the data is split or combined in a file or document and stored as dataset.
- The data is a graph and the file or document store imposes a hierarchical structure on the data. It is limiting.
## Attract Non Technical/Day to Day Users
### What are the use cases that can only be done with Solid?
- Having an app that have multiple data sources that used to be in Silos, but now are in our Pod
- Come to Rahul's session. Calculate the total carbon emissions for a specific product.
- Two different user interfaces that use the same data, but one that's geared towards non-technical people and one that's geared to technical people
- Could have different picture viewing apps
- Or music listener. One to just listen, and another to organize data.
### Applications to attract Day to Day users
### Attract UX People
- Provide a way for UX people to get the models and build the UX on top of it
- Ease them into the Solid Ecosystem by not forcing them to create a Solid Pod behind the scenes and still decide where they want to put their data later on.
- Local First: At the point people want to store it, it syncs with the server.
- The user can migrate all the data from the app to your own Pod.
- For an app developer, they don't want to reduce their audience
-
- Angelo Veltens: The solution isn't one app that's really nice. It's an ecosystem of apps that are working together. We want to have multiple apps and people realize the data works well together.
- Make getting a Solid Pod a low barrier to entry
- FedCM is a way to let browsers handle login
- [solid oidc fedcm demo](https://github.com/liquid-surf/fedcm-demo)
-
### Usable Consent UI
### Usable Data Browser
- Would like to implement as a browser extension, but the mozilla APIs aren't ready for it
- Struggled with Authorization especially with the differences in WAC and ACP. ACPs are hard to make user friendly.
- Diversity is slowing us down (like WAC vs ACP). We have 6 different notification mechanisms. There's not one thing with top down design.
### Verified to be working still apps
### Discovering Apps (open with this app/ Launcher app/ App store)
- Similarly a registry of pod providers
- Example https://mastodon.social/@jg10/112326389693444312
- Enable the discovery of apps that were previously authenticated as well as any app in the long tail of the web
- - https://solid.pondersource.com
- We know that a certain file is an image, or a recipe, so that can list the apps that you can open it with.
- A shape respository would have a mapping between shapes and applications that are compatible with it
- Needs to be an standard app manifest (like in SAI) to describe the capabilities of an app
- We should be able to programatically determine which application can open certain data
- We made an application called https://sparqlexplorer.app it can ask a view if the data can be displayed on a view.
## Clear Specification and Tests
## Pagination
- https://github.com/solid/specification/issues/227
## Bootstrapping of a Form View from a Shape
Existing solutions:
- Overview https://github.com/SolidLabResearch/Challenges/issues/19
- https://github.com/SolidLabResearch/FormGenerator
- https://github.com/SolidLabResearch/FormViewer
- shacl-form
## Repo of web components for displaying a specific shape
## UI that allows you to swap out views and data sources and protocols
## Where to save non-personal data
## New backend services like sending an email
Other example: I would for example like to have a solid server-side processing HTML page
of my portfolio based on the data within my Pod. Instead of having to create an external application that does this for me.
## canIUse for different Solid Servers
## Application Template for different languages/frameworks
## More libraries than Just Inrupt for Auth
Problem statement:
Example of Inrupt forcing Silent Reauth instead of enabling developers to store refresh tokens
## ActivityPub Support
- Related work https://activitypods.org/
## More Solid Data Modules (for reconciling Shapes)
- Perhaps automatic reconcilation
### More apps that overlap and augment eachother
## World Searchable
- Support for Federated SPARQL? (https://www.w3.org/TR/sparql12-federated-query/)
### Text Search
### Semantic Search
FYI: This was removed from the Solid Spec
## How to use data types other than RDF
- Huge datasets like time series data
- Trinpod.us is doing tests with lots a data
## Provenance
### Use cases
- Personal verifiable information (ID, etc..)
- Certificates and degrees
- Chat
- Example: Check papers concerning "blockchain" layers on top of Solid to still enable the decentralisation
- Must be user comprehensible
## Documentation Consistency
- Specs vs Forums vs Solid Web vs Inrupt docs
## Interop with existing other systems
- Curl to interact with current Solid Pod
## Consistant Bot Authentication between servers