# W3C Solid Community Group and Social Community Group Joint Meeting

* Date: 2023-12-05T16:00:00Z
* Call: https://meet.jit.si/solid-cg-social-cg
* Status: Draft

## Present
* [Sarven Capadisli](https://csarven.ca/#i)
* [Virginia Balseiro](https://virginiabalseiro.com/#me)
* [Ted Thibodeau Jr](https://github.com/TallTed) (he/him) (OpenLink Software)
* [elf Pavlik](https://elf-pavlik.hackers4peace.net)
* Maxime Lecoq
* [Michiel de Jong](https://michielbdejong.com)
* [Rahul Gupta](https://cxres.pages.dev/profile#i)
* [Sébastien Rosset](https://activitypods.org)
* [Jeff Zucker](mailto:[e-mail])
* [Aaron Coburn](https://id.inrupt.com/acoburn)
* [Tantek Çelik](https://tantek.com/)
* [Matthias Evering](https://solidweb.me/testpro/)
* [Emelia Smith](https://hachyderm.io/@thisismissem)
* [Tim Berners-Lee](https://timbl.inrupt.net/profile/card#me)
* [Pierre-Antoine Champin](https://solid.champin.net/pa/profile/card#me)
* Juan Caballero (bumblefudge)
* Philippe Le Hegaret
* [Angelo Gladding](https://ragt.ag)
* Dmitri Zagidulin
* Bob Wyman
* a
* Evangelos Pragkalakis
* Steve Bate
* OMN

---

## Announcements

### Meeting Guidelines
* [W3C Solid Community Group Calendar](https://www.w3.org/groups/cg/solid/calendar)
* [W3C Social Community Group Calendar](https://www.w3.org/groups/cg/socialcg/calendar)
* [W3C Solid Community Group Meeting Guidelines](https://github.com/w3c-cg/solid/blob/main/meetings/README.md)
* No audio or video recording, nor automated transcripts without consent. Meetings are typically transcribed and made public. If consent is withheld by anyone, recording/retention must not occur.
* Join queue to talk.
* Topics can be proposed at the bottom of the agenda to be discussed as time allows. Make it known if a topic is urgent or cannot be postponed.

### Participation and Code of Conduct
* Join:
* [W3C Solid Community Group](https://www.w3.org/community/solid/join)
* [W3C Social Community Group](https://www.w3.org/community/socialcg/join)
* [W3C Account Request](http://www.w3.org/accounts/request)
* [W3C Community Contributor License Agreement](https://www.w3.org/community/about/agreements/cla/)
* [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.
* If this is your first time, welcome! please introduce yourself.

### Scribes
* Virginia Balseiro

### Introductions
* Tantek: Tantek Çelik, Mozilla, was co-chair of Social Web WG (2014-2018)
* bumblefudge (Juan Caballero): i'm researching ActivityPub "devex" and tooling, working very part-time on a tiny grant about same, no real understanding of Solid (high level or current-state!) so that would be appreciated
* Michiel de Jong: have worked on unhosted web apps for a while, interest in both social web and personal data stores including Solid. Affiliation: Ponder Source (a small non-profit software company).
* Philippe Le Hegaret: W3C/Strategy Lead
* elf Pavlik (independent): I co-edit Solid-OIDC with Aaron as well as Solid Application Interoperability. I also maintain https://github.com/janeirodigital/sai-js
* RG: Rahul Gupta, independent, Author of PREP, Co-author of Solid Notifications and contributor to Solid since 2020. Founder/Creator of [Syntropize](https://syntropize.com), a proposed Operating Environment which decentralizes data and applications.
* Emelia S: Emelia Smith, I'm a former Inrupt employee, worked on Inrupt Solid SDKs, now I work on trust & safety for the fediverse and contribute to Mastodon, Pixelfed, and am a technical advisor to [IFTAS](https://about.iftas.org/) (this is being announced today/tomorrow). Independent.
* Sarven Capadisli <https://csarven.ca/#i>, Independent. Solid CG Chair (2019-present)
* Ted "[TallTed](https://github.com/TallTed)" Thibodeau, [OpenLink Software](https://www.openlinksw.com/) (2000-present). Identity, Privacy, Linked Data, RDF, and related CGs and WGs. Primary coding language is English, evidenced by a kajillion change requests.
* Matthias Evering (@ewingson), independent, junior half pro pod provider
* Sébastien Rosset. Member of Virtual Assembly (France). Working since 2021 on [ActivityPods](https://activitypods.org) a software which aims to reconcile Solid Pods and ActivityPub.
---

## Topics

### Joint Call Background
* SC: https://lists.w3.org/Archives/Public/public-solid/2023Oct/0036.html , https://lists.w3.org/Archives/Public/public-swicg/2023Oct/0060.html

>Let's keep our broader challenges in mind, develop a mutual understanding of our technical designs, and look for ways to join forces.
>Let's dive into our specifications, implementations, and using what we need. What bridges can we build, solve together, understand better?

### Introduction to the Social CG
URL: https://www.w3.org/groups/cg/socialcg/

Proposed by [Sarven Capadisli](https://csarven.ca/#i).

* SC: [Social Web Working Group - Publications](https://www.w3.org/groups/wg/social/publications/)
* SC: [Call to Contribute to Prospective WG Scope](https://www.w3.org/wiki/SocialCG/WG_Charter_Discussion)
* TC: Social CG was established upon close of Social Web WG as a place to discuss specs produced by SW WG. Lot of focus on ActivityPub and Activity Streams. Evan P. has picked up editing of AP and regularly holding triage calls to go through issues, towards deeloping an errata and a revision of AP. Other specifications produced by SW WG are maintained in https://spec.indieweb.org
* bumblefudge: Forum: https://socialhub.activitypub.rocks/ & Proposals for standards: https://codeberg.org/fediverse/fep/

* TC: Mailing list was created about a year ago.
* TC: There's overlap in use cases and desired user flows that different groups want to solve. There's more to be gained from collaborating and trying to find ways for different approaches to interoperate.
* SC: I tried not to say too much on mailing list about joint meeting because when people hear Solid/Social they have different understandings of what those mean. Not just these two communities but other communities are working on similar use cases, personal data and so on.
* SC: Historically from Solid perspective we took "social" as a given but ot to the extend Social Web puts on social. Of course the web is inherently social and that involves personal data and social interactions, but Solid wasn't so much trying to address those open challenges that are going on in Scoial Web like third party control and major centralized services, social acitvities being poured into these, and ethical considerations and harm that can be done. Social Web a bit more generic about controlling data and access given and so on. There's understanding of similar use cases, but we should have had one of these calls years ago. But after Social Web WG, social web has been quietly moving in the fediverse as opposed to CG.
* SC: There's shared interest and we come from the same philosophy about having control over data and activities on the web.
* TBL: Whe we say Social Linked Data, how come does that not ??? the community group? We called it the read-write web. It was suggested that it should be called Social Linked Data. If you write a solid app you should always think in the context of all the other people's data. It's not just about one person, but all people. The social graph of people is important. On the other hand you can write any solid app as a generic ??? becuae Solid pod is agnostic as to what it uses. The pod doesn't care or know what app is used. All it does is authn/authz and not care about the type of data. So it's any linked data... the fact that it's called solid does not mean we're ??? we're focusing on the social use cases but it's a very generic platform.
* TC: Great summary. SC posed the question that we should have met earlier. There's interesting broader context, potential collaborating beyond efforts desribed today, there's internet archive conducting a series of dweb conferences to get ideas pollinating. Implosion of twitter has spurred a bunch of projects as well, BlueSky (https://atproto.com/), nostr. They take different approaches but enough commonalities to have bridges. The fact that is possible is due to a lot of the people here, to try to get just enough vocbulary/semantic compatibility, using same terms to mean the same things.
* TC: when SW CG started there was a workshop in 2013 where a lot of protocols and format were demostrated. Of those about 15 were proposed in SW WG. Of those we refined to 3 practical approaches with strong community interest, and that's how we ended up in the current situation. Adoption of these approaches has been a net benefit to all, despite general approach to standards being "you only want one". The HTML-based IndieWeb has continued to grow with software, services, users. ActivityPub and Mastodon have grown a lot as well, also in software, services, and adoption. There's also strong LD community with a bunch of apps. Each of these approaches has flourished.
* [in chat: bumblefudge: `bluesky : fediverse :: atproto : activitypub` https://atproto.com/]
* SC: I always found the philosophies and design considerations to be quite interesting. There's always different end result, and that's almost arbitrary, even within LD community people argue about their favorite format. So end result can be completely diferent. We had a bit of that on SW. The bigger concerns were actually whether we're solving the problems we agreed, broader societal issues on the web. I'm hoping we can re-focus in this partiular meeting or future meetings in revisiting some of those issues, because we want to have individuals/communities/groups/orgs to have a better sense of their data,how they can expressit and share it.
* [in chat: bumblefudge: to sarven's point about anchoring interop goals in userstories and realworld demand, i would suggest coming back to the user stories which were voted on in the minutes of one meeting but never really edited as a CG Note? https://github.com/swicg/general/issues/30 ]
* [ SC: bumblefudge, some user stories from the Solid end are documented here:
https://github.com/solid/user-stories ]
* BW: It's important to point out it's been wonderful to see different approaches, nostr approach is interesting because it is so different, but as a comunity we haven't put enough effort into consolidating the knowledge and ome up with appraoches that adopt from other systems' good points and leave behind bad point. We have not done a good job in reducing the unnecessary amount of diversity and have common learnings. One thing about Solid is that it gives user control/ownership over its own data, which AP systems do not. It requires the person running a instance to own the data. That's a great weakness ofhow we implement AP. The fact that the protocol works that way does not mean the clients need to work that way. By collaboration Solid + AP we would be able to move forward. Diversity has been wonderful but we ahven't done enough tofigure out how we can learn from others and reduce the need for diversity by coming up with common solutions.
* ES: There is the client-server protocol in AP but due to the way a lot of sevrers work it was never implemented. Maybe that gives indication of how we ended up with server centerted approach. as far as ??? it uses JSON-LD but we have ended up in fediverse with a lot of ??? that aren't part of any specification. Lots in more driven by implementations rather than standards.
* [in chat: bumblefudge: me says:the defacto standard of the Mastodon API 😄 ]
* eP: I'd like to clarif ythe scope of Solid and social web CG. I see Solid as more general/broad scope, where use cases I see use cases with healthcare, employment, supply chain, etc. Very broad use cases, while from my recalling of AP it is mostly about news feeds. Would be interesting to find the scopes of different projects and see the overlap. Narrow scope allows for simpler solutions.
* DZ: One of the things that SW can learn from Solid CG is access control. One of the main things lacking i nthe fediverse is the notion of access controls or friends' only posts. Among other aspects.
* BW: Along with access control, AP Collections are masssively underspecified which causes all kinds of trouble. Solid, because it is focused on storage, does a lot with collections. AP would benefit from learning how to get a useful specification for collections. On access control, I've been suggesting AP too look more like ODRL because ??? and we don't have that right now. The right to reply is something that comes up, right to search/index people's content. Set of rights AP user want to grant/withhold and we have no method of doing that. Solid is primarily concerned with traditional access control. We know there's big holes in AP. There's opportunity to do something useful by comining efforts.
* ES: Accross fediverse there's not a standard for authn or authz. it is whatever the sever implements. Some have implemented some form of auth/oidc, but very hit or miss and do not support certain server metadata endpoints [which would help interop]; a lot pf this is driven by a desire to adopt the mastodon API, the defacto standard [since authZ is out of scope for AP].
* TC: SW WG was able to agree on values and methodology, but the one about user owning data is something we had universal agreement on. Also on technical apporaches like "follow your nose" as a method of discovery. The whole concept of using [HTTP] URLs to represent individuals was also something we made sure worked well across specifications. On the point of fediverse not allowing users to own data, [diaspora pods] was trying to achieve that goal since 2009/2010, generic approach to data storage and ownership has been there for a long time, but strong focus on social aspects. AP can be used with any vocabulary, not restricted to AS. Micropub is a way to generically put data back/forth on a server, most often used on social data. Access control as area to learn from, protected/limited audiences is a strong interest in IndieWeb (e.g. using TicketAuth extension to IndieAuth which itself is based on OAuth), good that we're using the same underlying technologies like OAuth. Even user interfaces of very social media silos, and what we learn from interactions/human behaviors, is that there's a lot of access control needs that's beyond any existing protocol.
* [in chat: bumblefudge:
https://codeberg.org/fediverse/fep/src/branch/main/fep/5624/fep-5624.md <-- One proposal for AuthZ per object can be found here ]
* [in chat: ES: One thing that is certainly notable perhaps is that almost all activitypub servers require some logic to process incoming activities, so it wouldn't necessarily be directly implementable with Solid, which just currently gives very basic file-type resource access (e.g., you can't have a virtual object that's doing some logic to e.g., collate all your activities into an outbox) ]
* SC: +1. We've barely scratched the surface with the specs we have. Actual challenges/concerns people have today.

### Introduction to the Solid CG
URL: https://www.w3.org/groups/cg/solid/

Proposed by [Sarven Capadisli](https://csarven.ca/#i).

#### Solid CG Notes
* SC: [Solid CG Charter](https://www.w3.org/community/solid/charter/)
* SC: [Solid Technical Reports](https://solidproject.org/TR/)
* SC: [Proposal for Solid WG charter](https://solid.github.io/solid-wg-charter/charter/).
* SC: [Solid QA](https://solidproject.org/ED/qa) builds on the work of the [W3C QA Activity](https://www.w3.org/QA/Activity).

* SC: We have a charter, similar to other CGs. We had quite a bit of support in the group re: development. Details how we have new work items... resembles WG charter but with a lower bar for expectations. We have a chair election process which is currently underway, with three new chairs to be appointed soon.
* SC: TR covers protocol, notifications, authorization, and so on, with some data modeling as to how we express profiles, chats, all in progress.
* SC: We proposed a WG charter to W3C, we had some feedback from AC and horizontal reviews. There's some work we need to do to get the charterto express both the background but also suitable for the wider W3C and web community as to problems being solved.
* SC: Solid QA is quite central to the work we do. Test suite development as well as ???, how test coverages are connected, implementation report based on reviews of test authors and other reviewers. Based off W3C QA work, lots of great work there. We have a vocabulary that helps us express significant units of information in a spec.
* SC: There's an ocean of specs because Solid covers a broad problem space. We have implementation experience in server and clients.

## Open Discussion

Proposed by [Sarven Capadisli](https://csarven.ca/#i).
- [in chat: ES: I can perhaps also talk a bit about the moderation and trust & safety aspects of different ecosystems later? ]

### Authn/z

* SC: [IndieAuth](https://www.w3.org/TR/indieauth/) (and its [Living Standard](https://indieauth.spec.indieweb.org))
* SC: [ActivityPub/Authentication Authorization](https://www.w3.org/wiki/SocialCG/ActivityPub/Authentication_Authorization)
* SC: [Solid-OIDC](https://solidproject.org/TR/oidc)
* SC: [HttpSig](https://solid.github.io/httpsig/)
* ES: [OCapPub](https://gitlab.com/spritely/ocappub), extension of ActivityPub that uses OCaps for authenticating/authorizing different actions
* SC: [Web Access Control](https://solidproject.org/TR/wac), [Access Control Policy](https://solidproject.org/TR/acp)

* SC: I mentioned some of authn/z things because we have similar interests. There's also explorations on statement-level access control. We can;t dive in too deep into these, but heads up that there's work done and we need more collaboration from various people.

### Notifications

* SC: [Solid Protocol](https://solidproject.org/TR/protocol) uses [Linked Data Notifications](https://www.w3.org/TR/ldn/)
* SC: [Solid Notifications Protocol](https://solidproject.org/TR/notifications-protocol) uses [Activity Vocabulary](https://www.w3.org/TR/activitystreams-vocabulary/). See also [Notification Channel Type Registry](https://solidproject.org/TR/#notification-channel-type-registry).
* RG: [Per Resource Events](http://github.com/CxRes/prep) (PREP) is a light alternative to Solid Notifications Protocol. The companion [Solid-PREP](http://github.com/CxRes/solid-prep) specification specifies notifications when sent from a Solid resource. It uses the same messaging format as SNP, and therefore [Activity Vocabulary](https://www.w3.org/TR/activitystreams-vocabulary/) as well.
* TC: [Webmention](https://webmention.net/)
* SC: There's interest i ngeneral notion of notifications i nboth groups. Other work that we have, Solid Notifications Protocol, Webmention also one of the core specs out of SocialWeb. Not sure if there's new activity around notifications in SW CG, but work on AS and AP is still ongoing...
* DZ: We should talk about next steps.
* TC: I agree. We have a great set ofpeople, but want to point out we don't have everyone from every community and that's okay. Some folks are really passionate about getting details right. Creating a separate task force / ongoing meetings to discuss areas of overlap would be really positive.
* SC: This was an "intro" meeting so good idea to continue. Solid CG has a slot (2-hours) for special topics where we dive into topics. Happy to have something like that. Pick a topic and have everybody join. There's related topics about chartering. Solid is itnerested in WG and considerations in Social to continue under a WG. Maybe we cna hash out some understandings as to what makes sense i na WG charter given our shared interest in "social" problems.
* SC: Let's continue the dicussion on having task force / special meetings.

### Charters

* SC: Ack that Solid CG interested in a WG following its incubated work and there is interested in Social CG to continue some of the ongoing work under a new WG.

### Moderation and Trust & Safety

Proposed by Emelia Smith; Talking about approaches to moderation for Fediverse software, BlueSky, (maybe) Nostr.

* ES: There is talk in Fediverse about 'portable id', this identity could work across multiple servers. Many moderation tools are assuming that identity is tied to the server. A very common attack in Fediverse is spamming them with child abuse material and reporting the servers to get them offline. This could be used against solid servers as well. Bluesky takes the approach of labeling everything, combining manual as well as AI / ML based labeling. AP doesn't have much of a tagging mechanism for content, nor a way to track media by perceptial hashes to match them against malicious content registries.
* TC: I'd add to that list of attack vectors that there's also privacy issues we share across architectures and approaches; universal social-web problems (worth documenting separately from solutions)
* TC: Webmention has some precautions to avoid spam (Vouch extension - roughly summarized as having a friend in common). Even a simple gesture of someone liking someone else's post on another server, there is potential vector of abuse. Many don't display icons of responses to avoid potential offensive images. We tried approaches like pixelation etc. The larger point is there are a lot of attacks and attackers there. We are not in '60s and '70s of Internet protocols where everyone trusted everyone else. There is a lot to be gained here by collaborating on documenting various real world attacks and mitigation techniques both at UX and protocols levels.
* BW: Most of the converstaions are focused on 3-rd party moderation (censorship). We should talk about curation tools that should be in the control of the users. Simple things like "I don't want to see football in my feed". Bluesky has made some interesting moves by setting up ability for multiple external parties to tag posts, which should allow end users a lot flexibility on how they decide to read or not to read something. We also have W3C annotation technologies, which should allow associated credibility warnings. There is an article ??? which says we should give individuals rights to search for data etc.
* ...: We should build a systems which allow receipient of the data to have decision without deciding on the moderation.
* ES: Certain moderation is curtailing speach but often it is doing it in a way that user agreed with. The other side is the aspect of dealing with criminal / civil liability based on the content. If you host content with child abuse you might be hold liable. How are we protecting the server operator from mentioned liabilities. Example ???
* ES: I used to work as moderator for ???, many of those moderation tools are now used in Mastodon.
* ...: Another example, pornographic content, in Germany there is age verification requirement. UK just passed it own similar law. If content operator doesn't verify age for accessing mature content they can be hold responsible.
* BW: We need to distinguish between speech which is legal and which is illegal. There is a tremondous amont of moderation focused on legal speach. Those subject should be considered separetely. Relying on moderaors might require diverse choice of providers user can pick from. There is also problem of transparency of moderation rules.
* ES: There was a large Youtube producer who signed up for Mastodon. They had problem with posts they were seeing there. People replied that you have block button available. They replied that they don't want to use it based on their values. There are cases where platform operators need to leave some moderation up to the users.
* ES: ... case of misleading report which lead to someone's account being blocked.
* SC: We could capture it as use cases.
* https://github.com/swicg/general/issues/30
* https://github.com/solid/user-stories
* https://solid.github.io/authorization-panel/authorization-ucr/
* SC: There are other groups working on similar problems looking into moderation, harrassment, consent... (Mentioned in chat, some social implications questions: https://csarven.ca/linked-research-decentralised-web#addressing-social-implications e.g., factoring in domain expertise. It is complicated.)
* ES: IFTAS.org is working on documentation of legal requirements (GDPR, DSA, CSAM, etc) per jurisdiction; docs forthcoming (timeline unknown); The need for the documentation of legal aspects was one of the more highly ranked items in IFTAS's [moderator/operator needs assessment](https://about.iftas.org/moderator-needs-assessment/).
* elf: documentation helpful; may be good to contrast newsfeed/mostly-public architecture against private-by-default or ingroup/Access-controlled collab spaces.
* TC: There are alternative approaches to those problems. If we take the case "I don't want to see football". Stuff you want to focus on vs stuff you don't want to see. There are different approaches, one is moderation when you filter the stuff you didn't want to. The other one is being more deliberate on what you let in. If you consider metaphor of 'who do you allow in your own home', there is a challenge with culture that everyone should be allowed to do everything and then we can fix problems as they arrive. If someone misbehaves in a house party there are social conventions to deal with it, often there is no open invite but one chooses who they invite to the party. One can focus on positive what one looks for vs focusing on the negatives you don't wan't to.
* SC: We lean on ethical web principles https://www.w3.org/TR/ethical-web-principles/ and aim that technologies we work on are benefitial for the society.
* ES: Currently open federation seems to be a must. So we can compare it to open invite party. We can take steps with blocking a user or a domain. In Solid if you run a pod with a container which is writeable/appendable to the public. This opens an easy attack vectory. I recall a case someone being abused of pedophilia by someone using such public container to get illegal content on their server.
* SC: AP / Fediverse has friend requests which works in a similar way. How is that different as far as a request / notification ending up in a collection of some sort?
* ES: ActivityPub has this notion of doing a friend request. The service automatically establishes the relation. There is option of not accepting activities from people you don't know.
* ES: ... saying people from those webid provides can write to my pod. I control who has access to my realm of data.
* SC: The initial request, there is somethign that needs to be received. There is still something that ends up in some collection / container. The recipient has the responsibility to filter it. It is not that Solid leaves an inbox open or has limitation of not being able to process the notifications.
* ES: With open federation where anyone can send you any activity is different from having an open write container. In Solid you can set ACP which limits the access, there is also possiblity of requesting access. Solid is taking an approach to rule to allow access, while fediverse takes approach of denying access. ??? has somethign interesting where on first interaction they allow the server admin to ???. It is not specified in any standard.
* eP: I'm focusing on invite only spaces. So you don't rely on Solid to collaborate but rely on email or whatever else you currently use, even SMS. You send the capability URL and establish relations, and also existing channels to establish the relationship, and from there you have some certain trust.
* TC: Bringing up out of band trust, we have some interest in end-end encryption for social interactions. There are various proposals on that. Glad to hear that kind of invite / space creation thing. The IndieWeb approach has been a bit of a hybrid, e.g., homepages are public but then you are invited to participate / instead of any kind of being entitled to reply or federate type of cultural positioning. The social / user distinction, you can design protocols in various different ways. In AS2, following is part of the flow but we've seen other like DOPPLR, it was 100% private, friends-access. There was no request to follow. It was the opposite. I allow these people to see my stuff, and then they can decide whether to follow. Invite based rather than follow model. There are more models than reflected in protocols.
* ES: I'm trying to convince the Mastodon team to change their view on ??? . On the note of end-to-end encrypted communication. Good key management in the browsre. Web-crypto / Credentials API don't work in the browser for end-to-end.. tried to work but need to store the key somewhere and so need to use ??? and essentially encrypt the private key material that does leave the user's decice. ... [Passkeys](https://fidoalliance.org/passkeys/)
* BW: There are opportunities of working together. The key from activity point is to understand what colletion is, how to work with them, search them. The easiest point to start would be to leverage this knowledge in ActivityPub. Collections are heavily underspecified. I think the overlap with the collections can be the easiest thing to start addressing.
* TC: There are a lot of things we can collaborate on. It's great that we had this intro meeting. It is good for a pathway for focused discussions. For example to use our colletive implementation experiences to focus and iterate. From use cases down to implementations.
* ES: ...
* SC: From the persepective of W3C grups it is important to have this material residing in some sort of W3C / CG acknowledged space. For preserving this information, code of conduct etc. I'm not oposed to SocialHub, or other hubs, for example Solid has Solid Forum but that is not explicitly part of the Solid CG.
* ES: Is there a predefined process in W3C for joined CGs? We could look for a neutral space.
* TC: We tried to use w3c-social to capture use cases, we also used W3C wiki. There is benefit of having back and forth and the current state of things. We could always start something on W3C wiki. This could be fairly neutral W3C space. Past meeting minutes: https://www.w3.org/wiki/SocialCG#Meeting_minutes_archive
* SC: If we identify topics we can refer to existing repositories that we have. Even this minutes, if there are no objetions I will publish them in one of solid github repositories.
* ES: How about dedicated github org with a repo.
* SC: I know that CORS and proxies were a concern in both communities.

### Interop across classes of products

* SC: Similarities/Extensibility of Solid Protocol and ActivityPub Client/Server, e.g., client-server and server-server. Some background: https://www.w3.org/TR/social-web-protocols/

### CORS and Proxies