Re: CG Co-Chair Self-Nomination

Dear all,

all deadlines are Anywhere-On-Earth (see e.g. [1]) as stated in the call 
for nominations [2].
The deadline for nominations is thus in about 4h27min, Oct 16th 23:59 
UTC -12.

Cheers
Christoph

[1] https://www.timeanddate.com/time/zones/aoe
[2] https://lists.w3.org/Archives/Public/public-solid/2026Oct/0000.html




On 17/10/2026 08:29, Melvin Carvalho wrote:
>
>
> On Thu, Oct 15, 2026 at 3:22 PM renyuneyun <renyuneyun@gmail.com> wrote:
>
>     Dear Solid CG,
>
>     I'd like to do a self-nomination for the CG co-chair role. (Thanks
>     elf Pavlik for his great job in the position!)
>     (Sorry for sending again through a different email address, as the
>     previous ones appeared not getting out successfully.)
>
>     Info about myself:
>     I am Rui Zhao, formerly a postdoc at the University of Oxford,
>     started from 2022, under the EWADA project [1][2] -- it was also
>     the role most people in Solid know me of; I was in that role for
>     3+ years, and, starting from this year, am now an associate
>     professor in Tianjin University, China.
>     I have been very interested in different decentralized
>     technologies before knowing Solid. I started to investigate deeply
>     into Solid starting from Oxford, where we explored at lot of
>     different aspects related to or on top of Solid and other
>     decentralized Web technologies, to understand and improve online
>     privacy and user agency. During the period, I started as a fresh
>     person with little knowledge to Solid itself, and became someone
>     exploring the boundaries of Solid itself and proposing solutions;
>     I also got involved in the LWS WG, aiming to get the core idea of
>     Solid standardised as a W3C standard. In general, I consider
>     myself an active member of the Solid CG -- depending on different
>     periods, I join the CG calls roughly weekly or bi-weekly.
>
>     (Would be willing to give some pointers to my relevant works or
>     papers upon request. But in general, my research is on data
>     privacy and usage control.)
>
>     Although being an academic, development and prototyping is also
>     part of my daily life (yes, before the coding-agent era). I
>     created several Solid apps, ranging from libraries to research
>     prototypes to daily apps. This allowed me to have good
>     understanding of the current status quo of both Solid protocol and
>     libraries themselves, and the supporting documents and actual
>     sitautions of things in reality between apps and servers.
>
>     Based on the experience in the years, from both my own experience
>     of getting involved in Solid, as well as seeing and joining
>     activities around Solid, I saw lots of things worth improving,
>     lots of things already improved, and lots of things still needing
>     to be done. Some of them required lots of manual effort, dated
>     back in 2022, but they may be on a different situation nowadays,
>     due to the improvement of LLMs and relevant LLM-based / AI tools.
>     Here are a few that I think worth working on, but sometimes
>     overlooked (not only the work itself, but also the time/emergency):
>
>     1. Materials / Killer-apps / Motivators to attract bystanders, in
>     addition to (privacy-sensitive) tech savvies;
>     2. Common tools / libraries for Solid, so developers can start
>     with peace in mind;
>     3. Guidance of Solid and RDF data organization, possible examples,
>     so developers can easily achieve what they want in the data and
>     interaction level;
>     4. Cross-user interaction, after a solid foundation is set up;
>     this is very under-explored at the moment, as most efforts treat
>     Solid only as a single-user storage;
>     5. LLM/AI integration -- not just "in principle", but also
>     practical ways, including directly LLMs reading data, but and more
>     advanced workflows / interactions, e.g. RAG, agents (agents
>     representing the Pod owner)
>
>     Therefore, for CG, I feel currently it's in an interesting and
>     important middle place of several groups -- although not formally
>     defined -- and it should make use of this unique position well:
>
>     - LWS WG and Solid developers / enthuiastics
>     - Solid protocol and Solid developers
>     - Different Solid communities (regional, specialized implementors,
>     etc)
>
>
> Hi Rui
>
> With the nomination deadline now passed and you the only candidate for 
> the seat, it looks like congratulations are in order!
>
> Perhaps this deserves a new thread, but I am particularly interested 
> in connecting LLMs with Solid and would love to brainstorm with you. 
> Earlier this year, I connected an LLM to my JSS Pod via MCP:
>
> https://jss.live/docs/features/charlie
>
> I know Jesse and a few others are interested in this area too. What 
> have you been exploring, and where do you see the best opportunities 
> to use modern tooling to build killer apps?
>
> Best
> Melvin
>
>
>     This position allows the CG to make impacts on different things /
>     aspects. But with limited time and manpower, a prioritisation
>     needs to be established. Of course, there is no mandatory power of
>     the CG, so we can't magically require everyone to follow the same
>     guideline. However, a directive / indicative prioritised task
>     list, and a small group or assigned people of specific topics
>     would be of great benefit -- of course, this should / must not
>     take up all their time, and should be voluntary. This is the part
>     I feel the CG is current weak in, and should be improved -- to
>     have some sort of (written) plans, and try to progress and reflect
>     on the plan. (Indeed there were some attempts for planning for
>     Solid 26, not fully a CG thing, but that was...) In the meantime,
>     the goal of the plan should be made clear, in terms of what the
>     efforts would (want to) achieve: to expand the protocol (thus
>     interested to already Solid people), to support developers (make
>     developers more happy and potentially more developers), or to
>     attract outsiders (thus more users and potentially word of mouth).
>     ODI's stewardship should be a plus for both sides, though it may
>     have not been utilised well.
>
>     Philosophically, this relates to an idea I often feel (partially
>     also due to my other former experiences): decentralisation is not
>     the same as un-organised, let aside chaotic or random.
>
>     Of course, the exact prioritisation needs discussion, and the
>     working topics mentioned above may be a starting point. Some of
>     them (e.g. 2-4) can be a natural extension of what is currently
>     progressing, such as the inter-op and app / effort catalogues. I
>     would personally feel that something that can be *demonstrated*
>     and *directly used* are a very weak point of the Solid ecosystem
>     at the moment, and should be priroitised -- CG may not build it
>     directly due to its nature, but may consider prioritising
>     supporting of that, e.g. necessary protocol changes.
>
>     To avoid making this email too long, I'm stopping here. But always
>     happy to expand or clarify things upon request 🙂
>
>     (Also, some expanded topics may be found on my self-nomination
>     email in last round of co-chair election in Nov 2025; not
>     everything is the same, but many key concepts still hold.)
>
>
>     [1] EWADA Project description by Oxford Martin School (funder):
>     https://www.oxfordmartin.ox.ac.uk/ethical-web-and-data-architectures
>     [2] EWADA Project new website: https://ewada-ox.github.io/news
>
>
>     Best regards,
>     Rui
>