Design pattern for a builder request.

[masterworrall]

This question is straight from a "friendly" early adopter on our community forum.

"Hello, I am interested in creating an app for my community group, to register attendance and log all the attendees information, also for each of the attendees to be able to log on and register their attendance and access a monthly [x] questionnaire. Previously I had thought I had to have a server to do this, can you give me some advice please."

Our users are not developers - they are using our no-code Solid App builder.

What would the answer be?

[uvdsl]

Hi, this sounds like an architectural question to me.

From my perspective on this, a Solid Storage could provide a place to store the data (meeting attendance, questionnaire, answers, ...).
If there needs to be some custom business logic involved, this logic would go into the Solid App. Whether this Solid App is an SPA (front-end only) or requires an application backend is use case dependent. From the use case at hand, I'd guess that an SPA/PWA suffices here.

I then usually try to figure out where or rather under whose control the data should reside in the end.
For the specific use case for meeting attendance and questionnaire, I'd guess that a Solid Storage dedicated to the group in question would probably be a safe start. Of course, there would need to be a maintainer (controller) of that group's Storage -- maybe the group's chair or some other person.

From there, I'd then think about which (group of) users require which access (C?, R?, U?, D?) to which kinds of data.
Now, I'd usually start to think about data models - but given the use of a no-code App Builder, I am unsure what influence they have there?

Then start building the App and iterate over the prototype.

This is just how I'd approach this. Do you think an answer like this would be helpful?
If not, what is missing or what should be the focus?

[masterworrall]

@uvdsl thanks for taking the time. Appreciated.

It is definitely architecture and Solid has a different architecture to a centralised solution. We will discount any server side component; in its purest form the only parts of a Solid solution are the client side App and the (pod) server providing data services to the user of the App. Hence, the question.

As I understand Solid Storage is per user. I imagine this use case has an Administrator role who expects to see all the meetings, and all the Attendees for each meeting. I think the "questionnaire" should be addressed separately. If there is an App for the Administrator I presume it would be for creating meeting records, group member records and marking who was present for a given meeting.

Then there are the Group Members. I imagine they each have their own Solid Storage. They want to see the meetings and mark their attendance. Again, lets not think about the questionnaire yet.

If we follow your line about looking at the data "controller" we have to ask what that means in a Solid solution. We could think in a "centralised" way and say the "controller" is the Administrator role. In that case the App they use creates the meetings and attendance records and stores them in their Solid pod .

I presume the Group Member App would then have the means to "read" data in the Administrators Solid pod. They would be able to see the meeting records from that pod in their App. How does their App know where the meeting information is in the Administrators Solid pod?

The (Group Member) Attendees would have to write to the Administrators storage to provide a record for their attendance. I had also thought that only the Administrator should mark attendance but I referred back to my user and asked if Group Members should really be able to mark their own attendance, they said:

"Yes, but the attendee can not see the rest of the attendee names, the admin can see all names."

So, both the Administrator using their App and the Group Member using their's should be able to mark their attendance; in this line of reasoning both roles will "write" to the Administrators Solid pod. So the Administrator has to give access to their pod to Group Members.

I'll stop there because @uvdsl you said "..Solid Storage dedicated to the group.." and the line I was taking is that the role of Administrator shares their pod in some way because I am not aware of a means for a "group" to share a Pod in Solid. Is there such an architecture option or would it be achieved with an Administrator role sharing access to their Solid pod?

[uvdsl]

Generally speaking, Solid enables a wide variety of architectures. For me, answering "where/under whose control which data should reside" informs the architecture design. Whether it is a fully user-centric, decentralised architecture, depends on the use-case and its requirements. I'd just like to point out that even with Solid, you can build centralized solutions -- but you don't have to.

As I understand Solid Storage is per user. [...]

Yes, in the sense that there is an agent who controls the Solid Storage -- and usually that agent is the human user creating the Storage.
In general however, a Solid Storage may belong to any agent; a human user (natural person), an organization (legal person), a software agent, (or even a group of agents, see below) ... And Storages may be created by an agent for another agent such that the creating agent does not have any rights at the new Storage whereas the other agent (who the storage was created for) is setup as the controller of the storage.

I imagine they each [group member] have their own Solid Storage.

Yes, this is a very user-centric architecture, where any data a user produces is stored on their Pod. This is absolutely possible. Question here is: Where does the respective user-data link to? If each user only has a client-side application, and each user stores data in their own Pod, how do the individual participants connect their data such that the "Admin" (or meeting chair) can see who attended the meeting. There are again different approaches to solve this.

Moreover, data could become inaccessible because a group member left the group and revoked access or the member's Storage is unavailable -- this could lead to incomplete attendance reports. As pointed out earlier, if it is not a requirement of the use case that those attendance reports are complete, then we could think about a more decentralized/distributed solution.

How does their App know where the meeting information is in the Administrators Solid pod?

This is the question that any app faces when it connects with a user's Solid Storage. Data Discovery.
While there exist some approaches to this, there is no clear consensus in the community on how this should be done.
From hardcoding container paths (I'd rather not, but to get something working...), via type indexes or data registries of SAI, to even other approaches (DCAT anyone?), we see this still on our roadmap of problems to solve together: w3c-cg/solid#63

"Yes, but the attendee can not see the rest of the attendee names, the admin can see all names."

This is on one hand a question of how to set access rights: For example, for an attendee to only add their name to a list but not read the names that are on their, the attendee only requires an access mode of acl:Append but not acl:Read [WAC]. The admin does have read access.

On the other hand, depending on the information to store, it also goes deep into the details of how to model the data and how to structure the data model in (information) resources on the Storage. You can achieve pretty granular access management if required. For example, instead of just using one "file" (i.e. information resource) where each participant appends their name as present, the attendance list could consist of individual records of attendance. Per list, there could exist a container that contains the individual (information resources that contain the) attendance records. Attendees can POST their record to the container to append it, and potentially even be granted to read their own record, while not being able to read the container details or the container's other contents.

So the Administrator has to give access to their pod to Group Members.

Yes if "their" means the group's. Note that the administrator should only really be administrator. The shared storage should probably not be the personal storage of the human user acting as administrator of group meetings.

I am not aware of a means for a "group" to share a Pod in Solid.
Is there such an architecture option or would it be achieved with an Administrator role sharing access to their Solid pod?

In general, this is possible. As pointed out earlier, a Solid Storage is controlled by an agent who is identified by a WebID. A group of agents may be identified using a WebId. And, in Web Access Control, there is a mechanism acl:agentGroup that you can use to grant a group of agents access rights via the group's WebId. Then, any member of the group has the same access rights on the Solid Storage and they can thus be shared controllers of that Storage.

Agent Groups can be used to model role-based access control as well. So you can have a group of admins and a group of regular members. And in addition you are still free to grant individual access rights, e.g. to prevent a regular member to read other members' attendance records.

[masterworrall]

Hmm. So I wonder what response I should give the none technical person who has asked the question. Sent from Outlook for Android<https://aka.ms/AAb9ysg>

…

________________________________ From: Christoph Braun ***@***.***> Sent: Friday, January 30, 2026 10:48:41 AM To: solid-contrib/practitioners ***@***.***> Cc: Paul Worrall ***@***.***>; Author ***@***.***> Subject: Re: [solid-contrib/practitioners] Design pattern for a builder request. (Discussion #37) Generally speaking, Solid enables a wide variety of architectures. For me, answering "where/under whose control which data should reside" informs the architecture design. Whether it is a fully user-centric, decentralised architecture, depends on the use-case and its requirements. I'd just like to point out that even with Solid, you can build centralized solutions -- but you don't have to. As I understand Solid Storage is per user. [...] Yes, in the sense that there is an agent who controls the Solid Storage -- and usually that agent is the human user creating the Storage. In general however, a Solid Storage may belong to any agent; a human user (natural person), an organization (legal person), a software agent, (or even a group of agents, see below) ... And Storages may be created by an agent for another agent such that the creating agent does not have any rights at the new Storage whereas the other agent (who the storage was created for) is setup as the controller of the storage. I imagine they each [group member] have their own Solid Storage. Yes, this is a very user-centric architecture, where any data a user produces is stored on their Pod. This is absolutely possible. Question here is: Where does the respective user-data link to? If each user only has a client-side application, and each user stores data in their own Pod, how do the individual participants connect their data such that the "Admin" (or meeting chair) can see who attended the meeting. There are again different approach to solve this. Moreover, data could become inaccessible because a group member left the group and revoked access or the member's Storage is unavailable -- this could lead to incomplete attendance reports. As pointed out earlier, if it is not a requirement of the use case that those attendance reports are complete, then we could think about a more decentralized/distributed solution. How does their App know where the meeting information is in the Administrators Solid pod? This is the question that any app faces when it connects with a user's Solid Storage. Data Discovery. While there exist some approaches to this, there is no clear consensus in the community on how this should be done. From hardcoding container paths (I'd rather not, but to get something working...), via type indexes<https://solid.github.io/type-indexes/> or data registries of SAI<https://solid.github.io/data-interoperability-panel/specification/>, to even other approaches (DCAT<https://www.w3.org/TR/vocab-dcat-3/> anyone?), we see this still on our roadmap of problems to solve together: w3c-cg/solid#63<w3c-cg/solid#63> "Yes, but the attendee can not see the rest of the attendee names, the admin can see all names." This is on one hand a question of how to set access rights: For example, for an attendee to only add their name to a list but not read the names that are on their, the attendee only requires an access mode of acl:Append but not acl:Read [WAC]<https://solidproject.org/TR/wac>. The admin does have read access. On the other hand, depending on the information to store, it also goes deep into the details of how to model the data and how to structure the data model in (information) resources on the Storage. You can achieve pretty granular access management if required. For example, instead of just using one "file" (i.e. information resource) where each participant appends their name as present, the attendance list could consist of individual records of attendance. Per list, there could exist a container that contains the individual (information resources that contain the) attendance records. Attendees can POST their record to the container to append it, and potentially even be granted to read their own record, while not being able to read the container details or the container's other contents. So the Administrator has to give access to their pod to Group Members. Yes if "their" means the group's. Note that the administrator should only really be administrator. The shared storage should probably not be the personal storage of the human user acting as administrator of group meetings. I am not aware of a means for a "group" to share a Pod in Solid. Is there such an architecture option or would it be achieved with an Administrator role sharing access to their Solid pod? In general, this is possible. As pointed out earlier, a Solid Storage is controlled by an agent who is identified by a WebID<https://www.w3.org/2005/Incubator/webid/spec/identity/>. A group of agents may be identified using a WebId. And, in Web Access Control<https://solidproject.org/TR/wac>, there is a mechanism acl:agentGroup that you can use to grant a group of agents where the group is identified with a WebID. Then, any member of the group has the same access rights on the Solid Storage and they can thus be shared controllers of that Storage. Agent Groups can be used to model role-based access control as well. So you can have a group of admins and a group of regular members. And in addition you are still free to grant individual access rights, e.g. to prevent a regular member to read other members' attendance records. — Reply to this email directly, view it on GitHub<#37 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/BFSQXYNLN7PNU5GCVK6Q2UT4JMZITAVCNFSM6AAAAACS44H7OOVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTKNRUHE3TMMY>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[uvdsl]

In short, I'd say:

• yes, you do not need a special server in the use case at hand
• a Solid Storage can be used to store the data
• a Solid App can be used to create, process and read the data
• define the requirements in the use case,
  • who should have which access rights on which data
  • who should control the data (every user on their own? a group admin?)
  • ...

And based on the answers you get, @masterworrall, you'd need to see whether your no-code Solid App builder can be used to fulfill all the requirements or which requirements cannot be fulfilled by your tool.
With that knowledge, we can identify then the tooling that is missing in order to help your client.
Maybe you not only need a no-code Solid app builder but a no-code Solid solution builder?

[masterworrall]

:-) . ok, thanks @uvdsl .

[mrkvon]

Paul @masterworrall, would you be interested in taking this project to Practitioners' coding session, in order to develop the architecture and build a proof of concept? Do you see similarity, or any differences to what elf Pavlik proposed? It could be a joint effort.

The next meeting is (tomorrow) Thursday 2026-02-12 at 15:00 UTC, we're still confirming the topic we'll take on. This could be a good alternative for tomorrow, or a potential topic for one of the next meetings. WDYT, would that be relevant for you?

[mrkvon]

Update: we have a confirmation for a different project tomorrow. The question above stands, for one of the future sessions. 🙂

[masterworrall]

sorry for late reply. I did put my users request here to solicit some discussion and education, so happy for you to pick this up in the group. I might be able to get the person to put a face to the request.

However, I think the patterns needed to satisfy the requirement would also be covered with Elf Pavllik