12:34:23 <RRSAgent> RRSAgent has joined #social
12:34:27 <RRSAgent> logging to https://www.w3.org/2023/09/13-social-irc
12:34:27 <Zakim> RRSAgent, make logs Public
12:34:28 <Zakim> please title this meeting ("meeting: ..."), pchampin
12:34:58 <pchampin> meeting: SocialWeb data portability - TPAC 2023
12:35:10 <eprodrom> scribe: eprodrom
12:35:38 <eprodrom> chair: dmitriz
12:36:25 <eprodrom> dmitriz: this topic is very popular. A criticial feature of interoperability is data portability between ActivityPub instances
12:36:40 <eprodrom> dmitriz: microblogging, forums
12:37:56 <eprodrom> dmitriz: migrate accounts (actor profiles), migrate content
12:37:56 <eprodrom> dmitriz: including social graph (followers, following), events, content
12:37:56 <eprodrom> q+
12:37:56 <eprodrom> dmitriz: talk about in-progress specifications
12:38:28 <tantek> present+
12:38:28 <dmitriz> present+
12:38:28 <eprodrom> present+
12:38:28 <pfefferle> present+
12:38:28 <pchampin> present+
12:38:36 <dmitriz> scribe+
12:38:37 <tantek> tantek has changed the topic to: Social Web Incubation Community Group (AKA SocialCG / SWICG) https://www.w3.org/wiki/SocialCG. Chat log: https://chat.indieweb.org/social/ currently W3C TPAC session: https://www.w3.org/events/meetings/46ce9082-710a-4fe2-8cf8-5dcdc207c877/
12:38:40 <dmitriz> eprodrom: One agenda item I'd like to add is - I did a portability report https://w3c.github.io/activitypub/data-portability-report.html
12:38:48 <eprodrom> eprodrom: propose reviewing https://w3c.github.io/activitypub/data-portability-report.html
12:38:51 <n8s> n8s has joined #social
12:39:30 <dmitriz> eprodrom: the goal of this report was not to propose any new data portability systems, but to cover the state of data portability in the AP world, today in 2023
12:39:43 <dmitriz> ... in particular, this would be guidance for developers and end users, to understand what their options are
12:39:44 <bumblefudge__> bumblefudge__ has joined #social
12:39:45 <tantek> ^ would suggest putting that in the Abstract of the report
12:39:47 <bumblefudge__> https://w3c.github.io/activitypub/
12:40:00 <dmitriz> ... first section, I gave a probably exhaustive catalogue of what 'Your Data' might mean
12:40:16 <dmitriz> ... in two major sections. When we talk about a federated system, there is the data that exists on your own account server,
12:40:36 <dmitriz> ... but then of course there's the data on other servers
12:40:51 <dmitriz> ... so, on your own servers, there's your actor id / identity, various URIs, actor profile properties (name, avatar, links, etc)
12:40:59 <dmitriz> ... and the profile URI (which can be distinct from actor id)
12:41:23 <dmitriz> ... you have the Outbox (a collection of all activities the actor has done), and also, as part of that, are reactions (each activity or created content can have a creation of Replies, Likes, and Shares)
12:41:48 <dmitriz> ... the Inbox is everything that the actor has received through subscriptions or direct messaging. There are uploaded files. Followers and Following collections
12:42:03 <dmitriz> ... there's the Blocks collection (of blocked users), and also a Public Key that's used for HTTP Signature requests.
12:42:23 <dmitriz> ... what is distributed on other servers: the user's Actor ID is in others' Followers/Following lists.
12:42:40 <dmitriz> ... there are links in various @mentions etc. Object IDs that track back to their canonical location
12:42:46 <dmitriz> ... as well as the URIs for uploaded files
12:43:04 <dmitriz> ... so the upshot here is -- we have a LOT of distributed data, that either lives on the account's server, or distributed among other servers
12:43:15 <dmitriz> ... in terms of data portability, we have two main mechanisms today for doing Data Portability
12:43:35 <dmitriz> ... one is Domain-Based Data Portability (when you own your own domain), which lets you transfer implementations, hosting services, etc.
12:44:18 <dmitriz> ... and the second one is Mastodon's (& others) Move action
12:44:18 <dmitriz> ... which is a technique of moving accounts and activities to other implementations or instances
12:44:18 <dmitriz> ... the analogy I always use is - similar to WordPress
12:44:39 <dmitriz> ... you can Export your content, comments, accounts, etc, and then Import it on another implementation or another domain, etc.
12:44:50 <dmitriz> ... you can do something similar on a Mastodon server on the Fediverse.
12:44:53 <capjamesg> present+
12:45:16 <dmitriz> ... but the overall pattern is important. Fairly basic, but critical
12:45:38 <dmitriz> ... there are a number of limitations with Domain-Based portability. 1) you have to own the domain, and 2) You have to run your hosting server on the fediverse
12:45:57 <dmitriz> ... there are a number of hosting services that offer this, but you do need to use one that lets you map a domain onto the hosting system
12:46:02 <dmitriz> ... this is a fairly high barrier to most users
12:46:14 <dmitriz> ... the other challenge is -- we don't have a standard format for Exports / backups
12:46:36 <dmitriz> ... we have a start on this on Mastodon - it outputs a single user's data. But there is not Import on the other side, ironically
12:46:38 <dmitriz> ... we have an open Github issue on this
12:46:54 <tantek> q+ to note challenges with AP/AS @-mention interop/portability https://github.com/snarfed/bridgy-fed/issues/493 and consider BAF for backup format
12:47:03 <dmitriz> ... lastly, different implementations may use different URI patterns for Activities and content. For example, Mastodon's profile is at /users/username, other impls may use other patterns
12:47:13 <Loqi_> [preview] [gRegorLove] #493 Add support for publishing mentions
12:47:15 <dmitriz> ... so backing up and restoring, might not map correctly
12:47:24 <capjamesg> Not AP-specific, but micro.blog has experimented with a "blog archive format" for blog content that has a HTML format with microformats. Not directly applicable, but may be interesting: https://indieweb.org/blog_archive_format.
12:47:24 <dmitriz> q?
12:47:29 <eprodrom> ack eprodrom
12:47:46 <dmitriz> tantek: no questions about technique per se,
12:48:03 <dmitriz> tantek: I appreciate the framing of the scope of the document. I think that literally what you said belongs in the abstract of the doc
12:48:17 <dmitriz> ... so like, just copy/paste what was scribed, into abstract! :)
12:48:36 <dmitriz> ... I appreciate you mentioned the React mentions in particular, interop wise
12:48:52 <dmitriz> ... to be specific, the way Mastodon and Friendica do @-mentions, Bridgyfed has tried the examples in the spec & some variants, and has been unable to get @-mentions to work
12:49:22 <dmitriz> ... for example on Bridgy, when I @-mention you, it's not able to generate a correct activity or object to notify you, specifically
12:49:30 <dmitriz> ... I'm not sure if that's in scope, but it's one of the issues
12:49:42 <capjamesg> Good point, Tantek.
12:50:09 <pfefferl_> pfefferl_ has joined #social
12:50:11 <dmitriz> eprodrom: yeah, I think the general idea with portability, is that the @-mention stays, links to the old domain, but that hopefully redirects you, etc.
12:50:18 <capjamesg> Yeah we should decouple domain portability vs. data / instance portability.
12:50:23 <dmitriz> tantek: agreed, yeah, and there's still various challenges there
12:50:38 <dmitriz> tantek: lastly, you mentioned there's no official backup format. There's a challenge there with blogs in general
12:50:50 <dmitriz> ... there's a default meme in general "Just use RSS", but that doesn't always work
12:51:01 <tantek> https://indieweb.org/blog_archive_format
12:51:05 <dmitriz> ... so there's one specific format that (?) Reese worked on - blog archive format
12:51:17 <dmitriz> ... would that suit the needs for account backup & restore?
12:51:18 <dmitriz> q+
12:51:21 <dmitriz> ack tantek
12:51:21 <Zakim> tantek, you wanted to note challenges with AP/AS @-mention interop/portability https://github.com/snarfed/bridgy-fed/issues/493 and consider BAF for backup format
12:51:23 <capjamesg> I like the plain text, structured, ZIP-based format of the blog archive format.
12:51:28 <Loqi_> [preview] [gRegorLove] #493 Add support for publishing mentions
12:51:34 <dmitriz> tantek: it also includes replies, responses, etc
12:51:48 <tantek> ack tantek
12:51:49 <dmitriz> ... its' very close to modern AS2 profile
12:52:16 <capjamesg> https://wordpress.com/support/export/
12:52:18 <capjamesg> ref ^
12:52:36 <dmitriz> dmitriz: also worth looking at WordPress export format
12:52:36 <capjamesg> IIRC WP format was a lot of XML?
12:52:48 <dmitriz> tantek: I think it informed the blog archive format, too? I think it does more / is superset
12:53:00 <capjamesg> More semantics are included in blog archive format.
12:53:05 <eprodrom> q+
12:53:19 <dmitriz> q-
12:53:48 <dmitriz> eprodrom: I want to mention the fact that - I believe that Mastodon uses is a collection of AS2 data
12:53:58 <dmitriz> ... and since that's the native format for AP, it makes a good candidate
12:54:04 <dmitriz> ... so it's a good starting point
12:54:04 <capjamesg> Worth discussing re: AS-encoded data for an archive format.
12:54:20 <dmitriz> ... I'd like to talk about this second data portability technique that is used on the Fediverse right now, and that's the Move action
12:54:28 <tantek> q?
12:54:43 <dmitriz> ... it's a mechanism that's used for - primarily used to move from one Mastodon instance to another. However, there are other implementations that support the technique
12:54:56 <dmitriz> ... it is limited in scope, but has some good outcomes that cover data portability
12:55:17 <dmitriz> ... the mechanism is relatively simple: a user has an existing Actor at username@oldexample, then creates a new actor at username@newexample
12:55:30 <dmitriz> ... then add an 'alsoKnownAs' property, points at the old actor
12:55:41 <tantek> FYI micro.blog has some support for Move: https://www.manton.org/2022/12/02/moving-from-mastodon.html
12:55:42 <dmitriz> ... which denotes "I'm wiling to accept Move requests from old actor"
12:55:55 <dmitriz> ... similarly, adds a 'movedTo' property to the old actor profile
12:56:00 <Loqi_> [preview] [Manton Reece] Moving from Mastodon to a new instance or to Micro.blog
12:56:08 <dmitriz> ... then finally, initiates a Move activity, from the old account to the new account
12:56:10 <tantek> FYI2 and Bridgy Fed is working on Move support: https://github.com/snarfed/bridgy-fed/issues/330
12:56:28 <Loqi_> [preview] [snarfed] #330 Add account migration (Move) support
12:56:39 <dmitriz> ... this goes out to all followers, who check & validate, then unfollow the old account, and follow the new account
12:56:47 <dmitriz> ... once this happens, the old account's profile URI _will_ automatically redirect to the new account's URI
12:57:09 <dmitriz> ... there is not an automated mechanism for moving the Following list. But, mastodon allows downloading the old following list, and importing it into the new account
12:57:17 <dmitriz> ... it's a manual step, to download a CSV file & re-import it
12:57:47 <dmitriz> ... the results are - we have the redirect between profile URIs, the follwers list is close to what was at the old account. the following list does the export/import thing.
12:57:59 <dmitriz> ... the old account's Following list is empty, and the network has everything updated
12:58:22 <dmitriz> ... this technique is primarily moving the social graph. It does not cover the content, uploaded files -- those remain at the old URLs at their old IDs
12:58:37 <dmitriz> ... if the old account's server is down, it is no longer possible to move to another account
12:58:42 <dmitriz> ... and it does not work if the old server's account is blocked by followers
12:59:02 <capjamesg> Interesting.
12:59:13 <dmitriz> ... so a common occurrence -- a server gets massively de-federated, users then try to move from that server, but are unable to, because the old server is not accepted (the Move actions bounce)
12:59:17 <capjamesg> I haven't read many docs about that. Worth highlighting more.
12:59:30 <dmitriz> ... so, if it gets de-federated due to a small percentage of bad actors, but it traps everyone else
12:59:33 <timbl> timbl has joined #social
12:59:35 <capjamesg> That feels *really* important to address.
12:59:40 <bumblefudge__> ^^
12:59:47 <dmitriz> ... I'll pause here. that covers the primary mechanisms for data portability on the Fediverse right now
12:59:48 <tantek> capjamesg, feel free to q+ if you want to add to the conversation on the record
13:00:00 <capjamesg> q+
13:00:21 <dmitriz> ... I know that Firefish and Friendica have somewhat enhanced mechanisms for this Move practice that may move over some content, or mirror some content. I haven't tested it out, but would love to track these
13:00:22 <eprodrom> ack eprodrom
13:00:23 <bumblefudge__> q?
13:00:33 <tantek> chair: dmitriz
13:01:03 <eprodrom> capjamesg: point made with regard to people being isolated warrants a great discussion.
13:01:25 <eprodrom> capjamesg: being left in that predicament is difficult for the average user
13:01:27 <dmitriz> q+
13:01:32 <dmitriz> ack capj
13:01:52 <capjamesg> q-
13:01:57 <eprodrom> tantek: should we track this problem with an issue?
13:01:57 <capjamesg> Thank you, kindly!
13:02:03 <eprodrom> eprodrom: yes
13:02:11 <eprodrom> bumblefudge__: there are feps to address
13:02:21 <dmitriz> ack dmitriz
13:02:32 <bumblefudge__> https://codeberg.org/fediverse/fep
13:02:41 <eprodrom> dmitriz: feps = Federation Extension Proposal
13:02:52 <bumblefudge__> ^ Extensions to the Spec (defining behaviors and/or data models not defined in the core spec)
13:02:58 <eprodrom> dmitriz: there are 2 interesting feps - identity proofs, signed objects impact migration
13:03:46 <eprodrom> dmitriz: main challenge if old server is dead or uncooperative or defederated enough that on-line dataportability will not work
13:04:04 <eprodrom> dmitriz: to address these challenges, alternate technique to do this cryptographically
13:04:19 <dmitriz> https://codeberg.org/fediverse/fep/src/branch/main/fep/c390/fep-c390.md
13:04:19 <eprodrom> dmitriz: signatures prove equivalence
13:04:49 <bumblefudge__> (insofar as signature can be checked by discovering key material for that actorID...)
13:05:09 <eprodrom> dmitriz: use a key or DID, sign old account, set up movedTo and alsoKnownAs, sign new account
13:05:20 <bumblefudge__> (and insofar as new server lets you BYO key :D )
13:05:20 <eprodrom> dmitriz: can claim a continuation of identity
13:05:38 <eprodrom> dmitriz: can perform most of the activity based on equivalents
13:05:46 <eprodrom> q+
13:05:48 <tantek> q+ to ask how would you sign a dead from server and ask does it matter which direction the defederation occurs? at the from defed the destination, or at the destination defed the from?
13:06:21 <eprodrom> dmitriz: only possible if user has key control, or old server lets you export your keys
13:06:34 <eprodrom> dmitriz: warning and red flags on exporting private keys
13:06:56 <tantek> q?
13:06:59 <dmitriz> scribe+
13:07:01 <eprodrom> ack eprodrom
13:07:21 <dmitriz> eprodrom: I do want to note that although the technique - the FEP covers doing the signature, it does not cover the Move protocol
13:08:16 <dmitriz> ... the implication is - you can USE it for Move activity, but doesn't describe the full procedure
13:08:37 <dmitriz> ... so it needs more work / additional specifications of that
13:08:37 <dmitriz> ack tantek
13:08:38 <Zakim> tantek, you wanted to ask how would you sign a dead from server and ask does it matter which direction the defederation occurs? at the from defed the destination, or at the
13:08:38 <Zakim> ... destination defed the from?
13:08:39 <capjamesg> Thank you dmitriz for highlighting the FEP.
13:09:00 <eprodrom> tantek: fascinating proposal. Uncovers a lot of really good use cases. Should be documented independent of a solution
13:09:09 <bumblefudge__> dmitri: 3 diff failure cases: old server down, old server uncooperative, or older server defederated enough to not be cooperated with
13:09:18 <capjamesg> Have we discussed what happens if a domain relapses and is taken over?
13:09:25 <dmitriz> ohhh good point (re read-only servers)
13:09:26 <capjamesg> (maybe this has never happened, but just thinking about a fail case)
13:09:38 <eprodrom> tantek: dead server, uncooperative server, read-only server, defederation
13:10:01 <dmitriz> @capjames - also good variation (I think that's a variant of "old server is down" or uncooperative), but it's a different flavor - a possibly actively hostile server
13:10:02 <eprodrom> tantek: do you mean one or both servers are defederated (to v from, from v to, both)
13:10:22 <capjamesg> dmitriz Yeah. Is there a case where a server becomes "untrusted" due to malicious activity?
13:10:35 <eprodrom> tantek: read-only: archive server like Wayback Machine backup
13:10:37 <dmitriz> @capjamesg - definitely!
13:10:50 <tantek> ack tantek
13:11:08 <dmitriz> eprodrom: that IS a technique people use for blogs, websites, etc. of scraping the Wayback Machine, and using that to recover data
13:11:24 <eprodrom> tantek: useful to document these approaches
13:11:26 <eprodrom> eprodrom+
13:11:27 <dmitriz> +1 to documenting the use cases!
13:11:35 <capjamesg> +1 Tantek.
13:12:05 <capjamesg> ++ DID is key to bsky.
13:12:12 <eprodrom> tantek: Blue Sky considered data portability from scratch uses a DID
13:12:29 <eprodrom> tantek: supposedly portable across servers, without actual proof since no other servers
13:12:55 <dmitriz> good call (doing an A/B analysis on Blue Sky's identity approach and this FEP)
13:12:57 <dmitriz> q?
13:13:00 <eprodrom> tantek: is there a possibility of a bridge?
13:13:01 <bumblefudge__> q+
13:13:04 <eprodrom> q+
13:13:31 <eprodrom> bumblefudge__: the way Blue Sky uses DIDs is something we have been following, also Nostr. we == DID people
13:13:36 <capjamesg> ref: https://atproto.com/specs/did
13:14:05 <capjamesg> > The AT Protocol uses Decentralized Identifiers (DIDs) as persistent, long-term account identifiers
13:14:18 <eprodrom> bumblefudge__: BlueSky and Nostr are private key == identity, retrofit compatibility onto URI-identity
13:15:09 <dmitriz> q?
13:15:13 <dmitriz> ack bumbl
13:15:13 <eprodrom> bumblefudge__: identity proofs FEP tries to be DID neutral, should not matter what DID method you use, can't think of DID methods won't work, including Blue Sky DID Web, DID PKH (Ethereum wallet style), if delegate to wallet
13:15:33 <sandro> q+ to suggest the requirement that users be able to easily, privately, non-destructively, test the system against various failures
13:15:49 <bumblefudge__> q-
13:16:16 <dmitriz> eprodrom: we haven't taken note of it during this conversation, but I do want to talk about it quickly, which is - the topology of the Fediverse today
13:16:20 <dmitriz> ... in terms of the locus of control
13:16:40 <dmitriz> ... I think there is a structure/topology that is common on the Indieweb, in which a single implementation supports a single user, on a single domain
13:16:55 <capjamesg> Good assessment re: IndieWeb.
13:17:02 <dmitriz> ... all under control of that single user. On the Fediverse today (so, Mastodon, Pleroma, Firefish, etc), we have a different common topology
13:17:56 <tantek> overlap with examples like WordPress where an "instance" can have one or a few users
13:17:56 <dmitriz> ... which is - hundreds/thousands/more of users, who use a single domain, they have a weak affinity of that domain (picked it from an arbitrary list),
13:17:59 <dmitriz> ... with a volunteer admin, not a paid service
13:18:03 <capjamesg> Agreed.
13:18:37 <dmitriz> ... this is not universal, but very typical. Because of the low affinity between user and domain service, the requirement of portability (of moving from server to server), it's very common
13:18:44 <dmitriz> ... so in Mastodon world, it's very common to talk to people who have moved 5-6+ times
13:18:52 <dmitriz> ... so the needs for portability is extra high
13:19:32 <capjamesg> Agreed.
13:19:32 <dmitriz> q?
13:19:32 <capjamesg> Blog posts!
13:19:32 <dmitriz> ack eprod
13:19:32 <eprodrom> ack eprodrom
13:19:32 <tantek> +1 eprodrom big distinction in locus of control
13:19:32 <tantek> q?
13:19:32 <tantek> ack sandro
13:19:32 <Zakim> sandro, you wanted to suggest the requirement that users be able to easily, privately, non-destructively, test the system against various failures
13:19:32 <dmitriz> ack sandro
13:19:46 <dmitriz> ohhh man, "backups you don't test are useless" --- +1 !!!
13:20:08 <tantek> "how do you test a social server profile backup?" (paraphrased from sandro)
13:20:11 <eprodrom> sandro: a user requirement. backups that you don't test are useless. Need to know that social backups are working, without breaking or undoable effects
13:20:38 <tantek> mirroring++
13:20:38 <Loqi_> mirroring has 1 karma over the last year
13:20:39 <eprodrom> sandro: common example is for users on social services to have backup accounts on same service
13:20:41 <dmitriz> q+
13:20:42 <tantek> testing++
13:20:42 <Loqi_> testing has 1 karma in this channel over the last year (3 in all channels)
13:20:54 <capjamesg> Mirroring feels complicated to the average user?
13:21:08 <eprodrom> sandro: excellent for peace of mind
13:21:13 <tantek> capjamesg not if you call it a "backup account" which lots of IGs have
13:21:27 <tantek> (and they do it manually!)
13:21:59 <eprodrom> dmitriz: what additions will we need to add to the core data model
13:22:04 <eprodrom> eprodrom+
13:22:07 <eprodrom> q+
13:22:15 <dmitriz> q-
13:22:17 <dmitriz> ack eprod
13:22:42 <dmitriz> eprodrom: so, I think one mechanism that Sandro alluded to here - having the ability to back up the content that's created. Preferably "hot backups"
13:22:51 <dmitriz> ... of activities, uploaded files, social graph
13:23:19 <dmitriz> ... and I think Sandro was suggesting having an "alt" account type of hot backup. The other thing is of course, a static backup on an external storage
13:23:33 <dmitriz> ... and having the location of that backup travel with activities & files as they go around the network
13:23:52 <dmitriz> ... so that if the content is inacessible, you can try it at this alternate location
13:23:53 <capjamesg> q+
13:24:00 <eprodrom> q-
13:24:13 <dmitriz> ack capj
13:24:50 <bumblefudge__> q+
13:24:52 <eprodrom> capjamesg: writing blog post about all thought processes on this issue, let's collaborate on proposed additions
13:24:59 <dmitriz> ack bumbl
13:25:00 <eprodrom> q+
13:25:24 <capjamesg> ++
13:25:26 <eprodrom> bumblefudge__: we should start FEPs based on use cases, not solutions
13:25:28 <dmitriz> q+ to ask where user stories should live
13:25:29 <capjamesg> Absolutely.
13:25:36 <eprodrom> +1 to use case first dev
13:25:44 <dmitriz> q-
13:25:45 <capjamesg> We should be use-case drvien.
13:25:49 <capjamesg> *driven
13:25:52 <bumblefudge__> q-
13:26:20 <Loqi_> yea!
13:26:33 <capjamesg> q+
13:26:36 <tantek> q+
13:26:37 <dmitriz> eprodrom: with 5 mins left in the session, I'd like to make a possibly controversial proposal -- just as we created a task force around Testing, would it make sense to take on this fairly large chunk of functionality, around Data Portability, as a task force of the Social CG?
13:26:40 <tantek> ack eprodrom
13:26:41 <dmitriz> ack eprod
13:26:52 <dmitriz> ack capj
13:27:16 <eprodrom> capjamesg: good to have a lead spoc for data portability
13:27:35 <capjamesg> I'd start with a prior art review too.
13:27:58 <capjamesg> Blog archive format, WP format, others of which we may not be aware but are used (Squarespace maybe etc.)?
13:28:05 <eprodrom> tantek: excellent focus area for attracting group attention; broaden to include identity/account, data/posts, social graph
13:28:20 <dmitriz> @capjamesg -- agreed, yeah
13:28:20 <Loqi_> @capjamesg has 0 karma in this channel over the last year (119 in all channels)
13:28:20 <eprodrom> tantek: should handle both of those examples
13:28:21 <dmitriz> q?
13:28:23 <dmitriz> ack tantek
13:28:26 <tantek> capjamesg++ restore :)
13:28:26 <Loqi_> capjamesg has 1 karma in this channel over the last year (120 in all channels)
13:28:27 <capjamesg> Why thank you :)
13:28:42 <eprodrom> q+
13:28:56 <eprodrom> q-
13:29:09 <eprodrom> tantek: backups should be in scope for data portability
13:29:11 <dmitriz> whoops didn't mean to --
13:29:19 <dmitriz> @capjamesg ++
13:29:40 <dmitriz> eprodrom: next step would be to find a volunteer lead
13:29:40 <capjamesg> A discussion for the mailing list
13:30:33 <eprodrom> RRSAgent, make minutes
13:30:34 <RRSAgent> I have made the request to generate https://www.w3.org/2023/09/13-social-minutes.html eprodrom
13:31:45 <eprodrom> Zakim: end meeting
13:31:46 <eprodrom> Zakim, end meeting
13:31:46 <Zakim> As of this point the attendees have been tantek, dmitriz, eprodrom, pfefferle, pchampin, capjamesg, +
13:31:46 <Zakim> RRSAgent, please draft minutes
13:31:47 <RRSAgent> I have made the request to generate https://www.w3.org/2023/09/13-social-minutes.html Zakim
13:31:53 <Zakim> I am happy to have been of service, eprodrom; please remember to excuse RRSAgent.  Goodbye
13:31:53 <Zakim> Zakim has left #social
13:40:43 <capjamesg> Thank you, everyone!
14:09:16 <tantek> tantek has joined #social
15:18:41 <tantek> tantek has joined #social
15:31:35 <dmitriz> dmitriz has joined #social