# SolidOS Team Meeting * Date: 13.05.2026 10:00 UTC * Call: [https://meet.jit.si/solid-operating-system](https://meet.jit.si/solid-operating-system) * Chat: [https://gitter.im/solidos/solidos](https://gitter.im/solidos/solidos) * Repository: [https://github.com/solidos/solidos](https://github.com/solidos/solidos) * Meetings home: [https://solidos.solidcommunity.net/public/SolidOS%20team%20meetings/](https://solidos.solidcommunity.net/public/SolidOS%20team%20meetings/) ---- ## Present attendees - Alain Bourgeois - Sharon - Timea - Noel De Martin - Matthias Evering - Tim ### Scribes * turboscribe.ai ## Some links - current work: Milestone 3m -> new profile design https://github.com/SolidOS/solidos/issues/275 - our project board: https://github.com/orgs/SolidOS/projects/2/views/7 - SolidOS designs: https://www.figma.com/proto/88xQawSSXzfQprEZPaKplZ/Solid-OS?node-id=1101-12533&starting-point-node-id=1101%3A12533&show-proto-sidebar=1 ## Topics ### Action Items - [ ] Sharon to finalize mobile layout fixes in profile pane - [ ] Sharon to go through all copilot review comments in solid panes PR - [ ] Sharon to review and perfect projects section - [ ] Sharon to test and verify all mobile improvements - [ ] Sharon to move button components back into profile pane temporarily - [ ] Timea to review all tickets in ProfilePane and provide feedback - [ ] Timea to work with Sharon on photo capture dialogue and add to contacts button - [ ] Noel and Michael to work together on SolidUI web components, focusing on both behavioral (solid-specific) and design system components - [ ] Noel to take lead on web components implementation - [ ] Noel and Michael to create one component (button or select) using new approach with storybook as proof of concept - [ ] Noel and Michael to review and address issues in PR comments - [ ] Noel and Michael to update SolidUI code structure as they see fit, with freedom to decide approach - [ ] Michael to support with accessibility improvements - [ ] Michael to complete accessibility ticket on ProfilePane - [ ] Michael to optionally explore browser HTML improvements in Meshlib - [ ] Michael to consider working on [friends page (social pane)](https://github.com/SolidOS/solid-panes/tree/main/src/social) design implementation later - [ ] Alain to look into updating dependencies for SolidUI, profile pane, and solid panes - [ ] Team to discuss with Jeff about migration path if significant changes are made to [his web components](https://github.com/SolidOS/solid-web-components) library - [ ] Team to ask designer about icon set preference (Lucide vs alternatives) - [ ] Team to decide on [open source font](https://matrix.to/#/!wAfwwonbRnRLYejFOR:gitter.im/$wjQHKNd2JbSEVJ5bER0Q-pNtmrjvDiHTCQxE7TngRFM?via=gitter.im&via=matrix.org&via=chat.semantic.works) from three suggestions and have designer update Figma designs - [ ] Team to add conventions and guidelines document to Git repository, possibly in SolidUI ### Round table ### Technical discussions #### Matthias visualization feedback * https://github.com/serverproject-dev/solidweb.app/issues/4 #### Add to contacts #### Where to put Headless component * Jeff web components repo: https://github.com/SolidOS/solid-web-components which we want to continue as is but refactor. * Tim's initial work: https://github.com/SolidOS/solid-ui/pull/743 #### PRS and accessibility of profile-pane * https://github.com/SolidOS/profile-pane/issues/310 * Timea to look at the othe PRs from Michael. #### Relation between what Noel is doing and RDF Forms * work is done on: https://github.com/orgs/SolidOS/projects/2?pane=issue&itemId=154710288&issue=SolidOS%7Csolidos%7C246 where I liked Tim's pull request too. ---- This template is based on the [W3C meeting template](https://github.com/solid/specification/blob/main/meetings/template.md) [Code of conduct](https://github.com/solid/process/blob/main/code-of-conduct.md) # AI transcript Final Summary of Entire Transcript (All Parts Combined) ======================================================= Across the full meeting, the team focused on: - **Rapid onboarding of new team members (Michael and Noel)** and scaling development processes. - Defining a clear **UI architecture split**: - Headless, behavior-only web components for reuse. - Styled Solid OS design system components for internal UI consistency. - Strong emphasis on **standardization of frontend development practices**. - Ongoing work toward releasing the **Profile Pane**, which is the immediate priority. - Handling **accessibility fixes across multiple repositories** (Profile Pane, Solid UI, Meshlib). - Addressing **branching strategy improvements** to support multiple developers working in parallel. - Resolving **technical inconsistencies in infrastructure**, including Mashlib/JSS version mismatches. - Managing **RDF forms evolution**, including: - Refactoring into its own repository. - Long-term reintegration into Solid OS after design system stabilization. - Introducing and then **temporarily de-scoping a new “Add to Contacts” feature** to avoid delaying the release. - Improving **project management structure**, including: - Better branching strategy (feature/dev/staging). - Use of GitHub project boards and milestone tracking. - Positive organizational updates: - Team expansion. - Progress on NLNet grant follow-up approval. --- Full Meeting Summary ==================== ## Part 1 (begin 0' to 20') 1\. Meeting Opening and Context (0:00–2:57) =========================================== - Timea starts the meeting and confirms recording is active. - She welcomes everyone to the **Solid OS meeting on 13 May**. - Mentions that: - An AI system is taking meeting notes (HackMD is available but AI is primary). - Attendance list has been updated. - Introduces **new team member Michael**, referred by Jeff. - Notes scheduling constraint: - Michael cannot attend Wednesdays (works in the morning). - Mentions recent **two intensive onboarding/engineering sessions (Monday & Tuesday)**: - Focused on onboarding Michael and Noel. - Discussed improving engineering processes due to team growth. - Topics included: - Web components architecture - Solid UI vision - Profile pane technical issues - Branching strategy improvements (Alain is working on this) - States that sessions were recorded in Solid OS pod. - Action items were generated from those sessions, but are not reviewed in this meeting. - Main short-term goal: - Release a **bug-free, design-aligned Profile Pane**. - Target timeframe: **next week**. - Moves to roundtable discussion. --- 2\. Noel – UI Standardization & Component Strategy (2:57–5:45) ============================================================== - Noel summarizes onboarding and architecture discussions. - Key point: need to **standardize UI development process**. - Observations: - Currently mixed approaches exist: - Native DOM manipulation (createElement, manual attributes) - Web component approach (proposed) - Proposal: - Choose one consistent UI building method and apply it everywhere. - Emphasizes: - Inconsistency in codebase is a problem. - Decision must be followed strictly once made. --- Component Architecture Proposal ------------------------------- - Noel explains a key architectural decision: - Two types of components: 1. **Headless components** - Provide functionality only (Solid-specific behavior). - No styling included. - Must be reusable across applications. 2. **Design system components (Solid UI)** - Include styling and consistent UI design. - Used internally for Solid OS interface. - Clarification: - Simple generic components (e.g., normal button) should belong to the **design system**, not headless layer. - Goal: - External developers use headless components. - Solid OS uses styled design system components. --- Action Item Proposal (Noel) --------------------------- - Noel suggests adding two discussion topics: 1. Where to place headless web components. 2. Accessibility issues and PRs for Profile Pane. --- 3\. Sharon – Profile Pane Work (5:55–6:17) ========================================== - Sharon reports: - Working on final bug fixes for Profile Pane. - Performing final checks and polishing. - No additional updates provided. --- 4\. Alain – External Work & Technical Context (6:22–9:16) ========================================================= - Alain reports work outside Solid OS: - Working on **NSS-related pull requests** from external contributor. - Following work on **GSS / ActivityPub system**. - Mentions: - ActivityPub web app interacting with pod data. - Indicates ongoing parallel research/engineering activity outside core Solid OS. --- 5\. Tim-related update (forms discussion context) --------------------------------------------- - Working on form-related systems. - Using Claude for assistance in development. - Timea PR workflow approach: - New modules: direct commits to main. - Legacy modules: refactor branches. - Alain - Wants technical alignment discussion between Noel’s work and existing form system in Solid UI. --- 6\. Matthias – Infrastructure Visualization (9:40–10:51) ======================================================== - Matthias clarifies his role: - Not deeply contributing to codebase but responsible for **public-facing server infrastructure**. - Reports: - Maintains **four servers**, all updated to latest NPM production versions. - Exception: - CSS stack not updated due to alpha version concerns. - Shares: - A **visual diagram of system architecture** (preferred visual thinking approach). - Emphasizes: - Keeping infrastructure current and stable. - Hopes contribution is still meaningful. --- 7\. Timea – Work Update and Coordination (10:59–12:23) ====================================================== - Timea reports: - Catching up after travel (London). - Handling childcare responsibilities (daughter ill). - Reviewing Sharon’s work. - Onboarding Noel and Michael. - Personal development work: - Improving: - Header - Left-side menu - Login popup - Coordination: - Working with designer in parallel. - Notes: - May need to leave early due to overlapping meeting with designer. - Suggests moving to technical topics. --- 8\. Matthias – Mashlib Architecture Alignment (12:24–13:39) =========================================================== - Matthias presents: - Visual architecture showing system stack. - Claims **Mashlib is central glue component**. - States: - All four servers run **Mashlib 2.2.0**. - Requests validation: - Wants confirmation that this architecture reflects reality. --- 9\. Technical Correction (Alain) (13:44–15:29) ============================================== - Alain corrects assumption: - JSS does NOT fully support Mashlib 2.0. - It uses an older version in practice. - Explanation: - System has compatibility issues due to: - Fixed default values in code. - Rewrite behavior preventing override. - Result: - Requires patching/modification to function correctly. - Concludes: - Issue is known and already partially addressed. --- 10\. Add-to-Contacts Feature Discussion (15:30–19:28) ==================================================== Feature introduction (Timea) ---------------------------- - Topic: new **“Add to Contacts” button** in Profile Pane. - Feature allows: - Adding viewed user to address book. --- Issues identified ----------------- - Bug: - “Add as contact” button appears **twice**. - UX concern: - Interface is confusing: - Mixed messaging for developers vs end users. - Proposal: - Involve designer to redesign interface. - Temporarily **disable feature in Profile Pane** (without deleting code). - Goal: avoid delaying Profile Pane release. --- Sharon’s response ----------------- - Agrees with simplifying for release. - Explains original intention: - Feature should work whether or not user has an address book. - Even handles cases where contacts are not public. - Suggests possible improvement: - Guide users to create an address book if missing. --- Timea conclusion ---------------- - Confirms: - Feature is too unstable/complex for current release. - Design changes and bugs would delay Profile Pane unnecessarily. - Decision direction: - Likely remove/disable feature temporarily. - Revisit after redesign. 11\. Add-to-Contacts Feature – Final Decision (19:28–20:26) =========================================================== 11.1 Discussion on continuation of feature work (19:28–19:41) ------------------------------------------------------------- - Alain suggests: - The **Profile Pane branch containing the “Add to Contacts” feature can remain active**. - Sharon can continue working on it within that branch. --- 11.2 Timea clarification on scope (19:42–19:48) ----------------------------------------------- - Timea confirms: - A dedicated branch for the feature already exists. - Sharon can continue updating it there. - Implies: - No need for immediate reintegration into main release pipeline. --- 11.3 Sharon’s preference (19:50–20:13) -------------------------------------- - Sharon expresses preference for a simpler approach: - Since the feature required significant effort to integrate originally: - It would be better to **keep it in the branch but deactivate the UI button in production**. - Reasoning: - The feature is not intended for long-term inclusion in its current form. - Reverting or reworking integration repeatedly would be inefficient. - Conclusion: - Preferred solution: **disable the button rather than maintain partial integration or repeatedly merge/remove code**. --- 11.4 Final agreement (20:15–20:26) ---------------------------------- - Timea agrees with Sharon’s proposal: - The “Add to Contacts” feature will be **temporarily deactivated**. - This avoids delaying the Profile Pane release. - Decision: - Feature remains in codebase but is not active in UI. - It will be revisited later after design refinement. - Timea closes topic: - Confirms agreement and ends the technical discussion on this item. --- ## Part 2 (20' to end 48') 1\. Introduction: Topic and Context (0:01–0:17) ----------------------------------------------- - Timea introduces the agenda item about **“where to put headless components”**, originally proposed by Noel. - She asks Noel to first explain what headless components are for team members who missed earlier discussions. --- 2\. Web Components Architecture Overview (0:18–2:01) ---------------------------------------------------- - Noel explains there are **two categories of web components**: 1. **Reusable “headless” components** - Intended for external developers. - Must be **style-free by default**. - Focus on behavior, not appearance. 2. **Solid OS-specific UI components** - Part of the **design system**. - Enforce consistent UI across Solid OS (e.g., buttons share the same style). - “Headless” means: - No styling included. - Equivalent to basic HTML elements with behavior. - Noel proposes: - The existing “Jeff components” / Solid Web Components repo could serve as the **home for headless components**, avoiding creation of a new repository. --- 3\. Clarification of “Headless” Concept (2:01–2:26) --------------------------------------------------- - Initial confusion is resolved: - Headless does NOT mean “style-only”. - It means **no styles at all, only behavior**. - Agreement reached on this definition. --- 4\. Repository Ownership and Structure (2:26–3:23) -------------------------------------------------- - Discussion on where components should live: - “Jeff components” exists within Solid OS GitHub organization. - Created by Jeff due to access limitations. - Timea explains: - Any structural changes must go through internal approval processes (ODI alignment). - General direction: - Continue working in the existing Solid OS repository rather than creating a new one. --- 5\. Naming Conventions and Packaging (3:23–4:00) ------------------------------------------------ - Noel suggests using a consistent naming prefix such as “Sol-”. - Team agrees: - “Sol” naming convention is acceptable and preferred. - Conclusion: - No need for new packages if naming and structure are standardized. --- 6\. Solid UI vs Web Components Separation (4:02–6:10) ----------------------------------------------------- - Alain mentions Tim has started a **new package for Solid UI web components**. - Timea explains: - Tim’s PR includes important work (especially RDF forms). - The intention is to merge: - Jeff’s work - Tim’s work - Noel’s architecture proposal - Key issue raised: - Current Solid UI components are difficult to style. - Noel responds: - Reiterates distinction: - Reusable components = no styles. - Solid UI components = styled, consistent design system. - He needs to review Tim’s PR. --- 7\. Styling Philosophy and Flexibility (6:11–7:20) -------------------------------------------------- - Timea clarifies: - “Headless” components may still have a **default baseline style** (e.g., purple theme). - Key requirement: - Components must be **fully themeable and overridable by users**. - Noel suggests: - “Headless” might be a misleading term. - Alternatives like “styleable components” are discussed. - Solid UI components should **not be easily overridden**, to preserve design consistency. - If customization is needed, developers should use native HTML components instead. --- 8\. Theming Discussion (7:55–8:25) ---------------------------------- - Tim adds: - UI should support **themes (light mode, dark mode, future themes)**. - Noel agrees: - Theming is possible and aligns with future Solid OS direction. --- 9\. Alignment Across Ecosystem (8:27–9:28) ------------------------------------------ - Alain emphasizes: - Importance of maintaining consistency across projects. - Avoiding fragmentation or forks. - Noel agrees: - The specific approach matters less than **all teams following the same rules**. --- 10\. Final Decision on Headless Components (9:36–11:22) ------------------------------------------------------- - Timea summarizes decision: - “Headless components” (behavior-only Solid-specific components like login buttons) will: - Live in the existing **Jeff/Solid Web Components repository** within Solid OS. - Actions: - Timea will communicate with Jeff about refactoring and alignment. - Noel will review Tim’s work for alignment. - Transition to next topic: PRs and accessibility issues. --- 11\. Branching Strategy Proposal (11:23–12:37) ---------------------------------------------- - Noel raises issue: - Current branching strategy causes collaboration problems. - Proposed solution: - A stable **main or develop branch**. - Continuous PR merging instead of waiting for release cycles. - Goal: - Enable multiple developers to work in parallel without blocking each other. - Concern: - Noel is not fully confident reviewing all PRs due to unfamiliarity with full codebase. --- 12\. Accessibility PRs Across Repositories (12:40–15:41) -------------------------------------------------------- - Multiple PRs exist (not just one): - Across: - Profile pane - Solid UI - Meshlib - Issue: - Accessibility problems are **system-wide**, not isolated. - Actions assigned: - Timea: review Meshlib + Solid UI PRs. - Sharon: review Profile Pane PR. - Some PRs are already partially addressed, but require verification. --- 13\. Layout and Remaining Accessibility Issues (15:44–16:21) ------------------------------------------------------------ - Noel notes: - Some issues relate to layout and hidden sections not fully fixed. - He may open additional PRs for remaining problems. - Timea suggests: - He should sync with Sharon to avoid duplication (especially regarding ARIA label changes). - Noel agrees: - He will pull latest changes and open PRs for unresolved issues if needed. - Topic closes. --- 14\. RDF Forms Discussion (16:22–18:13) --------------------------------------- - Timea introduces RDF forms topic in relation to Noel’s work. - Key points: - RDF forms remain part of the project but are **deprioritized until after profile pane release**. - They are part of a **grant milestone**. - Strategy: - RDF forms work will resume after UI system is stabilized. - Focus will later include: - Styling - Accessibility improvements - Integration with design system - Alain wants confirmation that this aligns with Tim’s work. - Tim confirms: - RDF forms work aligns well with web components direction. --- 15\. RDF Forms Long-Term Plan (18:41–27:24) ------------------------------------------- - Timea provides detailed historical context: - RDF forms improvement has been discussed for years. - A decision was made previously to move RDF forms into their own repository. - Tim’s recent PR (with Claude assistance) effectively implements this decision. - Current plan: 1. RDF forms continue to be used in Solid OS. 2. Improve bugs and functionality. 3. Separate RDF forms into its own repository (partially already done). - Current state: - Profile pane no longer uses RDF forms in its new design. - Future plan: - Reintroduce RDF forms once: - Design system is finalized. - CSS variables for light/dark themes exist. - Icon/component strategy is clarified. - Milestone: - RDF forms improvement is part of **grant milestone 3**. - Commitment: - RDF forms will not be dropped. - They will receive continued funded development. --- 16\. Development Process Improvements (Organizational) (27:24–end) ------------------------------------------------------------------ - Timea shifts to process improvements: - She will improve **project management structure**: - Better ticket splitting. - Feature branch organization. - Alain is exploring: - Development branch + staging branch + feature branches model. - Goal: - Faster development and better collaboration as team grows. - Team expansion: - Now ~5 active developers. - More structured workflow is required. - External developer update: - ODI developer will focus on **registration page**, not core Solid OS yet. - Team status: - With Michael and Noel joining, capacity is strong. - Bottleneck is now **process, not manpower**. --- 17\. Project Infrastructure and Planning Tools ---------------------------------------------- - Mentioned tools: - NLNet GitHub project board: - Tracks issues and milestones. - Will be used as primary backlog system. - Design system repository: - Contains UI designs for all panes. - Includes latest “social/friends pane” design. - Purpose: - Improve prioritization, tracking, and delegation. --- 18\. Funding Update (NLNet Grant) --------------------------------- - Important update: - Solid OS has been **accepted for a follow-up NLNet grant** (first threshold passed). - Next step: - Await questions or final confirmation. - Outlook: - Strong chance of receiving funding. - Overall tone: - Positive momentum and strong team growth. --- 19\. Meeting Closure -------------------- - Timea summarizes: - Strong progress across technical and organizational areas. - New team members + funding success. - Need for improved structure moving forward. - Meeting is closed with no further comments. --- # Example of full IA transcript of last 15 min In english Here is the final part of the transcript, which you should use to continue writing your detailed, accurate summary from where you left off. As a reminder, the summary should be organized into sections, each with its own header and the timestamp for when that section begins. Your summary should be in the same language as the transcript. Do not leave out any important information. Each section should contain one or more paragraphs. """ .... [Timea] (15:44 - 15:58) There you have to sync with Sharon because I think she already did some of that work. Not sure. I looked in the commits she did and there were some changes on the hidden ARIA labels. [Noel] (16:00 - 16:10) Okay, maybe what I can do, I pull the latest version of her ranks and whatever has not been addressed by Michael and it's still there, I open PRs. [Timea] (16:10 - 16:15) That would be fantastic if you can do it at that level. Thank you. [Noel] (16:18 - 16:21) Okay, and I'm done with this. We can move on. Thank you. [Timea] (16:22 - 16:52) Okay, there's one more technical topic on the list. But I, yeah, it's about the relation between what Noel is working on and doing the RDF forms. We touched a little bit, we touched on this aspect before, I believe, with Tim's initial work. Correct, Alain? [Alain] (16:58 - 16:58) Yes. [Timea] (17:02 - 18:13) Okay, so again, to see if there's anything left to discuss on it, Noel is going to look at the initial work from Tim. But mostly focus on the web components aspect. The RDF forms aspect is a to-do. So that has to be continued at some point, but after we finalise the profile pane release. I did not forget about it. And yeah, we will see afterwards, after the release, who will work on it and how to proceed. Yeah, but it's part of the grant. We have a milestone ticket about it, already some pre-work done about it. Maybe it's just worth mentioning the team's pull request on that ticket to make sure that we don't forget it. Is that okay for you, Alain? [Alain] (18:14 - 18:25) For me, yes. I want to be sure it's okay with Tim. Yeah. That it does not conflict what you are doing and want to do. [Tim] (18:27 - 18:36) It's what I'm doing with the RDF forms, it's very affordable for the web components. [Timea] (18:41 - 19:06) Tim, do you have any questions about the ideas of web components? About, I don't know, maybe we should go more into detail since we have more time, definitely, about what we are thinking of implementing and want to achieve. Are you interested in this aspect? [Tim] (19:08 - 19:15) Well, to a certain extent, I'll trust you to do the right thing with the web components because I'm not an expert on web components. [Timea] (19:18 - 27:24) Right. So, then, just to iterate, a few years ago, we talked about improving RDF forms. And this was an ongoing topic. We just did not have enough time. We didn't prioritise it. It is, to some extent, part of the grant, but to the point of making RDF forms its own repository. This is something that we decided a long time ago in the team, that it would be good. And now, Tim did this pull request a few weeks ago, where with Claude, he already took the step of creating an RDF forms repository. So, that decision, way back when, was now validated through Tim's work, I would argue. And the scope there is that we still use RDF forms in Solid OS. We improve its bugs and functionality. And what is part of the grant itself is, one, the move itself of the repository and of the code out of Solid UI, which is now in parts done by Tim's work. Great. Cleaning up the usage around RDF forms in each pane. So, for example, in the Contacts pane, I upgraded the code. It's, I would say, argue it's easier to follow the integration of a form, and the display of a form, and the ontology of a form. I also cleaned the ontologies themselves that drive a form in Profile pane and also in Contacts pane. At the moment, Profile pane does not use RDF forms anymore in the new design. This is going to be a follow-up work to bring it back into the Profile pane, if we so wish to. But only once the styling of RDF forms has also been updated. Once we will have a design system in place with CSS variables of light and dark, with figuring out the icons with components or not, whatever. When we have all that figured out, we will go back and improve the styling of the RDF forms and accessibility. This particular task is part of the grant itself. It's milestone three. I just wanted to iterate on this, that RDF forms is not going to be dropped off and forgotten about. We will not maybe achieve perfection by the end of the grant, but there's going to be considerate work done on it as well. And people will get paid for it as well. Okay, good. Just wanted to clarify that and mention, because I think it was not clear enough before. That being said, not a technical topic, but maybe a bit to our development process. I will personally go into the project management aspect of our work and make sure that we better split off in tickets feature developments. And so to be able to delegate and to create feature branches easier. This is what I want to look at possibly next week. Alain is looking into the idea of having the development branch and staging branches, staging branch and then feature branches. I will align with you on that maybe next week and just simply start doing it in development later. We'll see. This is for the purpose of being faster in development and integrating more developers. Since it was just me, me and Sharon, it was easy to sync more or less, but now it's getting a little bit out of hand. We are five people after all that actively develop. Also, I was a little bit too fast to mention that the ODI developer is going to work with us on solid OS code. Just wanted to mention that it's not 100% clear what her goal or tasks are, but the latest update is that she's going to improve the registration page. That is part actually of the pivot slash CSS code base, not solid OS. We will see. In any case, with Michael coming into the team, Michael and Noel, we are actually pretty well set. We just have to improve our development process in order to be fast enough for what we want to achieve. Otherwise, you always find in the meeting notes at the top links to we have an NLNet project GitHub board with all the issues and the milestones split up in tickets. That's actually what in the future we will go through as a backlog, as prioritising work, assigning work, making sure we don't forget tickets such as team's pull request. There's a link to the design system itself that contains the designs for all the pains and everything that the designer does and did so far. The latest design is the social pain, the friends. You can feedback that. You find it there. The link is in the meeting notes always. Yeah, and I think that's it organizatorically. I hope I didn't forget anything at the moment. Yeah, and also for the others to know, last week I got an update from NLNet. We have officially been accepted. We passed the first threshold of getting a follow-up grant on solid OS. Now we have to wait if they have questions. Or they just come with the final result. Let's hope for the best. We have good chances to get the follow-up grant. Yeah, I'm eagerly awaiting questions there if they have. Okay, so I would say good news on all fronts. New members, possibly follow-up grant. A lot of motivation. Yeah, good momentum. Okay, unbelievable what we managed everything in one hour. So if everybody's okay, doesn't have anything to add, I would adjourn the meeting for today. [Alain] (27:27 - 27:29) Can I stop recording? [Timea] (27:30 - 27:32) Yes. Yes, thank you