# Solid Implementer Feedback Session
* Date: 2021-10-21T14:00:00Z
* Call: https://meet.jit.si/solid-implementer-feedback
* Chat: https://gitter.im/solid/specification
* Repository: https://github.com/solid/specification

## Present

* Justin Bingham
* [Sarven Capadisli](https://csarven.ca/#i)

---

## Announcements

### Meeting Recordings and Transcripts
* No audio or video recording, or automated transcripts without consent. Meetings are transcribed and made public. If consent is withheld by anyone, recording/retention must not occur.

### Participation and Code of Conduct
* [Join the W3C Solid Community Group](https://www.w3.org/community/solid/join), [W3C Account Request](http://www.w3.org/accounts/request), [W3C Community Contributor License Agreement](https://www.w3.org/community/about/agreements/cla/)
* [Solid Code of Conduct](https://github.com/solid/process/blob/main/code-of-conduct.md), [Positive Work Environment at W3C: Code of Ethics and Professional Conduct](https://www.w3.org/Consortium/cepc/)
* Operating principle for effective participation is to allow access across disabilities, across country borders, and across time. Feedback on tooling and meeting timing is welcome.
* **Only implementers that have RSVP'd and been added to the agenda may speak, and only then during their alloted time. Editors may ask clarification during and after each block**

### Scribes
* Justin Bingham
* Sarven

---

## Feedback Sessions

### Meeting Format
Time: 2 Minutes (Justin B)

Goals:

* Learn which features or issues are high / low priority, and where applicable, adjust timelines or editorial priorities. This could impact the order in which features are integrated into Solid specifications
* Surface, discuss, and track open questions or concerns
* Learn the best way to structure subsequent sessions, and other mechanisms for feedback (e.g. surveys)

Each implementer on the Agenda will have at least 4 minutes to speak uninterrupted, and (approximately) one minute for clarifying questions from editors. Time can be ceded to others if all is not needed. Clarifying questions should be queued for efficiency, and may be taken offline due to time constraints.

### Ruben Taelman
https://github.com/comunica/comunica

Research on query execution in decentralized env. Works on comunica query engine as part of research
.. executes queries over one or more data sources. examples are rdf documents that can be stored in a pod
.. or sparql endpoints. reason i'm joining is to trigger some interest in the domain of adding more support for expressive query interfaces for solid data pods.
e.g have a large rdf doc stored in pod (e.g. 20-50M) - may not be efficient to fetch and query locally. in those cases - may be more efficient for data pod to expose more expressive query interfaces so query engines like comunica can detect avaiialbility of this interface and use it to have more efficient query execution. there is a need for a detection mechanism - e.g. via link header or data container description - to point to different search interfaces.

### Inrupt
Representatives: Osmar Olivo, Nicolas Mondada, Geoff Pirie

* https://inrupt.com
* https://docs.inrupt.com
* https://github.com/inrupt

OZ: Vp of Product at inrupt - joined by Geoff and Nicolas. Presenting a wishlist for the spec. Working with companies across different verticals. Based on interactions and use cases we're seeing, we have a prioritized roadmap of features. End of day solid is open protocol - we can implement stuff in our server, but if its not part of the spec its not doing any good for the community. Interop is a core tenant of solid.

*Sharing screen*

Tried to limit to top 10 - ended up with 12. Roughly in priority order -

Access Requests - today solid only focuses on sharing - works great for social media style cases - doesn't work very well for other kinds of use cases. Can't expect everyone to know which resources should be shared. WIll i as a patient know what i should or shouldn't share. Need to have some mechanism for an app to request data and for users to accept or reject it. We've implemented it at inrupt in server or developer tools. would be great to start seeing more conversations and finalizing this in interop and authorization and have a formal model for all servers and apps to request access aligns with next item (consent)

Access with Purpose - Consent is touchy - a legal term. When i request access, i should be able to say i want access to your pics for facial recognition.

Data Classification - Ability to classify data so we can request and query it

Access Control Policies - Based on app use cases, what's currently there isn't sufficient (WAC). Going live with millions of pods, but those will be on ACP

Secure notifications

Old auth tokens are a huge problem - apps are still using old ones

Data Validation super important

Query super important

Optional support for ACP or WAC - every feature has to be done twice. Should be optional to do once or the other if both are in the spec.

Import / Export

Multiple Pods to One Webid

All of therse are things that don't currently seem to be in the spec.

### Sarven Capadisli
* https://dokie.li/
* https://github.com/linkeddata/dokieli

Dokieli - project I've been working on since 2015 up through 2019 (then switched gears to focus more on specification work) felt that major barriers were server implementations and quality of servers. Dokieli is a client-side editor to write articles and annotate documents / facilitate social interactions. Semantic publishing. It can be used as a browser extension. Would eventually like it to see it native to the Web browser. Able to share things, pick people from contacts, reply - like a document editor, has memento, can embed data, have a graph view of underlying data (e.g. run it against the wac spec: https://solidproject.org/TR/wac ) - can then see the graph of data in any kind of document eg. specs, webpages... ( https://csarven.ca/linked-research-decentralised-web, https://csarven.ca/ , examples in the wild published by different parties: https://github.com/linkeddata/dokieli/wiki#examples-in-the-wild ) If anyone has used a doc editor of any sort - it's probably an important piece of software that you should have a web version of. can think of it as a way of transitioning from third party services (like google docs) to a doc editor like dokieli. annotate the web. Also able to drive slideshows (e.g. https://csarven.ca/presentations/linked-research-decentralised-web ) with annotations in different documents and urls.

Timbl: What does Dokieli need from the spec

SC: Not conflicting with classic web tech - HTML and RDFa are first class things that are needed for a document to have semantic publishing. Haven't seen anything remotely close to Dokieli to date. Spec comes fairly close to it, but in some cases it doesn't or may be concerning. If anything we look at docs all day, and need a solid app that lets you author / annotate / notify / request access - i should be able to do that.

### Janeiro Digital
Representatives: Justin Bingham, Jamie Fielder, Angel Araya, Eric Prud'hommeaux
https://www.janeirodigital.com/xform/

Justin: Called transform: existing stsysems that don't know anything about pods.. so thta we can get existing systems to integrate quickly qhile we transition to supporting natively. focused on health care. important for security issues. compartmantilisation for consent. we want different poeple to have a lot of information and to authorize read-write. we focused on interoperability. first bits: limitations of access control. lack of app authorization: fact solid-poidc provides clientid but we can't use it to auth clients. deficiency in inheritance model: giving access to photo1 ??? but brings bob's accss. the inability to graph ... gran sue access to photo1 because it has ??? from app that i have shared. we want crud style granularity. write allows you to do write, delet,e create and that limits some of hte granularity in authz. authz by credential. rather than saying bob to access this data. i want to auth ??? by presenting a credentials. nice for group based access. trying to standardise things like access request. maintain least privilege. thjis is hte data you can get. more poeple should be involved in supporting these problems. for interop we need more ??? if one pap breaks that app it is broken for all others. standard data pattern for integrity. as a consumer of that data who ??? to serve provenance.

Jamie: be notified on data change. push updates. pagination. transaction support; number of docs related individuall fine by colletively may be problematic.. support for decentralized identifiers e.g. did:web.

Justin: customers are asking about did:web.

Jamie: ?? we have to write custom code for pod provisioning..

Sarven: we have init `did:solid`: https://solid.github.io/did-method-solid/

### Alain Bourgeois
https://github.com/bourgeoa/solid-file-widget
https://github.com/bourgeoa/tiddlywiki-node-solid-server
https://github.com/jeff-zucker/solid-file-client
https://github.com/jefff-zucker/solid-ide

Not personally a developer but difficulty i have is the transition between the specification that have not historically been all written and where stated as a de-facto standard in NSS. The fact that it is changing is not a problem, but the problem is where it will be implemented. No visibility into what are the medium long-term of these changes. When trying to write apps, you are just trying to make them work on the actual server - but not knowing whether it will work in the future.

Example - authentication has changed - need to understand the new workflow of that. Not enough background to do it. When inrupt client changed, there wasn't migration from an old app to a new app. Doesn't help a basic developer to migrate their own apps. I haven't done anything with mine because I don't think I understand the changes. Docs are a bit messy.

A lot of discussion saying that NSS functionality will not be ported in CSS. That is very disturbing because I know it is not in new spec, but need somewhere the defacto standard - if your app is working on NSS you expect it to work on other servers when there are new changes.

Would like to see more visibility into spec process, more clarification, and better app developer experience.

JB: Question - what kind of visibility would be helpful?

AB: Need more long-term information. There's a flow of current information, but not enough long-term visiblity. We know its not next month for most of it. TIme of developers is not equal to time of developers doing implementation. Devs work along and doing jobs for 1-3 months and something else.

### Community Server
Representatives: Ruben Verborgh
https://github.com/solid/community-server

Couple of different things but most important are:

- Versioning is really important. If we say we implement solid spec - what does that mean? Ongoing source of confusion. Need to say this is the current state of the spec, at this specific version number.
- How hard is it to implement certain parts of the spec? Can we simplify it a little bit? Worried that implementing solid could be as complex as implementing a browser. What does a minimal solid server look like? Once it gets too complex there might not be many implementations.
- Identity - need to think must stronger about identity and how to deal with it. Have a webid but in practice need to deal with other IdPs. Don't have answers to mul;tiple IDs. What role does VCs play in that?
-

### Jeff Zucker
https://github.com/jeff-zucker/linked-bookmarks
https://github.com/jeff-zucker/jeff-zucker/solid-auth-cli (archived)
https://github.com/jeff-zucker/jeff-zucker/solid-file-client
https://github.com/jeff-zucker/jeff-zucker/solid-ide
https://github.com/jeff-zucker/jeff-zucker/solid-shell
https://github.com/jeff-zucker/jeff-zucker/solid-ui-components
https://github.com/jeff-zucker/jeff-zucker/rdf-easy
https://github.com/jeff-zucker/jeff-zucker/sparql-fiddle
https://github.com/jeff-zucker/solid/data-kitchen
https://github.com/jeff-zucker/solid/solid-node-client
https://github.com/jeff-zucker/solid/solid-rest

General concerns are: dealing with containers and a profile. it is not overspecified but leaves implementers questioning things. we can't depend on certain things in the profile.. it becomes cumbersome to figure out who/w/hat we are dealing wiht .im in favour of containers .. what ot expect there. directory in a regular filesysem. in terms of a profile: most important is hte preferences file... private stuff belongs there.. and there is nothign in the spec that does that. we need to deal with storage.. what is a storage / how do we find out about it. it need some clarification. i'd like to firm up what we want from a profile. some say that this is for the client to do. if not in the profile, put it yourself. i dont find that satisfactory. need some recommendations.. either to server implementers or pod providers.. so it is there out of the box.

Justin: do yo uhave some ideas for the containers

Jeff: most important for me is the media type. created, size.. are also nice.

### Christopher G. Prince
https://github.com/crspybits/SolidAuthSwift
https://github.com/crspybits/SolidResourcesSwift
https://github.com/SyncServerII/Neebla/

Excited to be here - working on a project related to user-owned data since 2015. Found out about SOlid in June - very exited to see a much larger projects on similar goals as mine. Project is an app on ios store called Neebla - all open source. All written (client) in swift, backend in swift.

Creating two swift language packages - one for authorization to solid pods, and one for accessing solid pod resources. Made some initial progress, now blocked. Most of that is related to knowing the differences across different server implementations. Happy to write those up in the agenda - have some links in my github repo. Impleemntation is working on NSS, but not on others without some tinkering. Main issue is knowing the differences across servers, and being able to resolve those problems.

Some questions and bigger picture issues - will leave those for some other time.

TIMBL: Ideal state for differences between servers are the tests. Make sure that stuff

### SolidOS
https://github.com/solid/solidos
https://github.com/solid/solid-ui

If you've using inrupt.net or solidcommunity.net, solidos came with the pod. This idea was like a phone or laptop, when you get a pod you get your "os". been around for years and years running on various solid servers even before NSS. Continuity of the spec is important. There's a lot of functionality being put in there. For example - it does live updates with websockets, if you have two versions of your app running against same data they'll be in sync. Live update really important - if we don't support those you have a problem.

For 6 years, when listing a folder, you got back name / type / size / last modified of things in the folder. If you've got images in a folder, it'll see that / offer a slideshow. Shouldn't be taking things out of the spec that loses functionality. If security is an issue - make sure there's a transition plan. For example - transition for auth was horrible for devs.

Really valuable to distinguish between Solid Protocol and these things where clients have to agree. Lots of client conventions for what SolidOS does (what it puts in type indexes, contacts, chat). What we haven't done well is written up shapes for things like this. Get type indexes, contacts, issue trackers, define in terms of shape so people can use them interoperability.

Also smart folders and smart groups would be valuable. VCs for client (not from server).

### GraphMetrix
Representatives: Fred Gibson, Kai Gilb, Roger Perry
https://graphmetrix.com/

Do TrinPod and we have apps. Focus is between construction apps and airline baggage + facial recognition / touchless using personal pod to do it.

Key thinfgs for spec - having a final spec on secure websockets. Have been holding off on it, but waiting until spec is finalized.

Need a lot of pods (project pods - eg. personal pod may have projects you collaborate on) - business pod (can't authenticate on it - arrived at through personal pod authentication). Don't think multiple pods per webid is important. If you say things about a webid on a pod you authenticate through your own personal one.

Using ACL owner to say that if i have acl owner on a pod, it means i have full r/w/c access on another. Could create a hierarhcy of pods you could control and own with a simple ACL owner triple. Will be more pods as time goes on (e.g. pod for a car)

Another thing they're doing - every r/w/c that a user does creates an event. Complete traceability. If there were a solid standard for what to use for auditing they'd be happty. Putting constellation of pods in production this week.

TimBL: +1 to organizations having pods. At the moment we have someone who owns the webid passwords. Someone goes in there and determines who has access to project pods. Want to run solidos projec tlike that. want to run solid project like that.

GM: when a user creates company pod - they add an acl for that user so they're the admin for the pod.

### Noel De Martin
* https://github.com/NoelDeMartin/soukai-solid
* https://github.com/noeldemartin/media-kraken

Feedback:

- I expressed some of my concerns about data discovery in [this comment](https://github.com/solid/specification/issues/227#issuecomment-773945439). I worry that I posted this comment several months ago and this is still being discussed. I believe this is an extremely important issue, and I'm not sure what needs to happen for this to be settled (for all I know discussions could continue for years to come). One example of how this is affecting me today is that my application, Media Kraken, is not usable in the community server. Sure, you can use it with a few movies and it will work, but I have 1800 movies in my collection and that means the app has to make at least 1801 network requests in every refresh.
- Recently I've been looking into the [SAI spec](https://solid.github.io/data-interoperability-panel/specification/), albeit from a distance until recently. My worry is that it seems a lot more complex than the [type index](https://github.com/solid/solid/blob/main/proposals/data-discovery.md#type-index-registry), and even though that may be warranted I think it can potentially be detrimental to interoperability. Most applications I see today don't even use the type index, so I have my doubts if something even more complicated will be used or continue being ignored. In my mind, the ideal scenario would be to have something like the type index as an entry point and applications could use more complicated features as needed. Personally, I don't think that my apps would need anything more complicated than "give me access to all resources of type X and tell me where to create them", at least for now.
- This is something I haven't looked into for a while, but as far as I understand ETAGs are still not supported by all servers, and I think that's because this is missing from the spec. In my case, this is important because I use the [Active Record pattern](https://en.wikipedia.org/wiki/Active_record_pattern) in my apps and models can get stale. My solution for now is doing a request before every write, but that's wasteful and it would be better if I could use ETAGs with an `If-Match` header.

### Ian Davis and Travis Vachon (Mysilio)
* https://github.com/understory-garden/understory.garden
* https://github.com/understory-garden/swrlit
* https://mysilio.garden (Application)
* https://mysilio.me (Pod Host)

Looks like we might run out of time for our session so I'll (Travis) add notes here. The biggest thing holding us back from really leaning in to Solid is spec churn - we've been building for a year and a half now and still don't have clear answers on two basic questions: "where should our application put data" and "how to we ensure the right set of agents have access to the data we create" - with the type index apparently deprecated and an in-progress switch (?) to a new access control spec it's hard as an application implementor to be certain that the choices we make now will be supported by the spec and server implementations later. As much as I'm excited for additions to the spec, the most valuable thing for me would be for the spec authors to settle at least these basic questions - "where do we put data" and "how to we ensure the right people have access to it" - and then build out a robust set of implementation examples, server support, client library support, recipes and other resources to help frontend developers build on top of Solid.

For what it's worth, I'd love to be part of this documentation effort - our bandwidth is pretty thin as we try to figure out how to make this project sustainable (investors tend to look at Solid and see it as a risk rather than a benefit at the moment!) but I would definitely invest some of my own time in making it easier for the wider community to get started building Solid apps and I think a more formal collaboration around documentation/community building would be something Mysilio would be open to.

While I'm excited about many of the "new features" discussed during this session, I am a bit worried that the spec editors and core implementors will spend more time hashing out new ideas at the expense of investing in polish and wider community understanding of what's in the spec now. - TV