15:02:08 RRSAgent has joined #social 15:02:08 logging to http://www.w3.org/2017/06/07-social-irc 15:02:10 RRSAgent, make logs public 15:02:10 Zakim has joined #social 15:02:12 Zakim, this will be SOCL 15:02:12 ok, trackbot 15:02:13 Meeting: Social Web Working Group Teleconference 15:02:13 Date: 07 June 2017 15:02:14 nightpool: I'm too eager!!! 15:02:17 present+ 15:02:17 geppy: ajordan left you a message 6 days, 22 hours ago: I'm in love with octobox.io. thanks again omg 15:02:18 present+ 15:02:18 present+ 15:02:19 present+ 15:02:21 present+ 15:02:27 present+ 15:02:30 hm we need to figure out how to tell trackbot this is the CG meeting not the WG meeting 15:02:30 present+ 15:02:42 :) 15:03:04 volunteer for what? 15:03:08 scribing 15:03:11 present+ 15:03:28 Meeting: Social Web Incubator Community Group Teleconference 15:04:05 if not, I can scribe (and just type whatever's said in Mumble?) 15:04:21 present+ 15:04:29 i wrote something up on the wiki cwebber2 15:04:33 scribenick: MMN-work 15:04:54 scribing details https://www.w3.org/wiki/SocialCG#Scribing 15:04:55 https://www.w3.org/wiki/SocialCG#Scribing 15:05:01 cwebber2: First item is social working group update. I wasn't there, maybe aaron is better to represent it 15:05:06 MMN-work: if someone is continuing to speak prefix with `... ` 15:05:16 MMN-work has left #social 15:05:22 ben_thatmustbeme and I were on the call 15:05:30 MMN-work has joined #social 15:05:33 present+ 15:05:44 Expressing intent of "where" a message shows up (direct messages? etc?) See: https://github.com/w3c/activitypub/issues/196#issuecomment-304958984 15:05:44 [cwebber] Note that Pump.io already does this, and I think this may be the answer: inbox is still used for federation, but multiple streams can be presented to the user in terms of inbox / the "major" feed (which is all the main posts and comments and etc) / t... 15:06:08 q+ 15:06:56 Mastodon now highlights direct messages, but does not seperate them 15:07:17 cwebber2: First discussion is "where" a message shows up, this is regarding who a message is addressed to and where in UIs and feeds to show it (scoping) 15:07:44 cwebber2: But it seems everyone seem happy about it, so unless anyone has something to say maybe we can skip it 15:08:04 (missed who): what was the resolution? 15:08:23 cwebber2: Maybe I'm wrong about there being a resolution, but having a flag may be the best way to do this instead of a type 15:08:52 nightpool: Having a separate type would fail fast, so there are benefits to that. What are your thoughts on having separate inboxes? 15:09:24 to clarify: I meant seperate inboxes to psot to 15:09:27 cwebber2: An inbox serves two purposes in ActivityPub, a place where people post TO and where you read FROM. 15:09:30 s/psot/post 15:10:35 I thought we were pretty solid on calling it a "disposition"? 15:10:56 cwebber2: One option here on "where" is like a "follow" that maybe shouldn't show up in all feeds. [I missed the other option] 15:10:59 q? 15:11:40 ack ajordan 15:11:50 It appears I'm totally misremembering this. 15:11:53 "post" vs "mail", or "deliver" vs "notify" 15:12:17 nightpool: you mean using a fragment specifier to express an intent to address a subinbox? as in geppy.im/me#special-inbox ? 15:12:21 Right 15:12:30 I thought people had suggested that in the issue 15:12:36 but can't find it now 15:12:42 cwebber2: I'm having a little hard time keeping up. I'll keep trying for a while and focus more but we'll see how it goes. .) 15:13:15 cwebber: How about having separate types or different filtered inboxes? 15:13:48 I'm +1 on that 15:13:50 +1 15:13:50 How about a poll, not a resolution, regarding types/flags vs. inboxes? 15:13:54 cwebber: How about a poll, not a resolution, regarding types/flags vs. inboxes? 15:13:56 I don't think that's right. The receiver organizes their boxes, that makes it sound like the sender is organizing for them 15:14:27 present+ 15:14:42 cwebber: The receiver would still filter and inboxes would only be informative 15:14:49 saranix, ^^^ 15:14:56 +0 15:15:07 the properties would be informative to how the server can filter into the sub-inbox read endpoints 15:15:10 > The receiver organizes their boxes, that makes it sound like the sender is organizing for them <--- agree 15:15:11 +1 15:15:13 still causing cognitive dissonance. 15:15:27 saranix, are you -0 then? 15:15:41 -1 15:15:43 for inboxes 15:15:55 I think flag is the way to go 15:15:58 I feel like an informative flag is ideal (re: receiver or their useragent organizes their own inboxes), rather than a type that's more "you must do this". 15:16:04 Uh we're talking about flags 15:16:12 saranix: this *is* going to be a flag 15:16:15 +1 15:16:18 saranix, are you able to join the mumble call? 15:16:25 aaronpk: no 15:16:27 cwebber: There is confusion on IRC. It would be a flag. 15:16:30 saranix: it's, the server posts a message like {"@type": "Note", "directMessage": true} 15:16:33 Sorry, this informal proposal is "we either use flags or note types, and *don't* use different inboxes to post to" 15:16:35 saranix: to the *normal inbox 15:16:55 "but the server that a client is reading from may provide seperate inboxes to read from" 15:17:01 this is not clear at on all IRC 15:17:05 saranix: and then the server could decide to have another endpoint that's read *from*, but it's at server's discretion to filter there 15:17:07 what is the actual poll question 15:17:22 saranix: how you are with that solution I just described 15:17:31 to reiterate: 15:17:56 ajordan: Aren't we talking about the proposal on GitHub [some days] ago? 15:17:58 cwebber: yes, basically 15:18:10 (proposal on GitHub: https://github.com/w3c/activitypub/issues/196 ) 15:18:11 [annando] #196 How to differentiate between posts and private (direct) messages? 15:18:16 poll question is, how are people with either having a flag like described in https://github.com/w3c/activitypub/issues/196#issuecomment-304958984 <- this comment 15:18:16 [cwebber] Note that Pump.io already does this, and I think this may be the answer: inbox is still used for federation, but multiple streams can be presented to the user in terms of inbox / the "major" feed (which is all the main posts and comments and etc) / t... 15:18:38 and having the server filter into sub-inbox endpoints, at its discretion, for *reading* (but not for other servers to post to it, they would still post to the same endpoint) 15:18:49 q+ 15:18:58 saranix: I think that matches your flag and the server deciding to post to their boxes thing? 15:19:06 +1 flag (in particular, a general `disposition` flag) 15:19:12 yes 15:19:13 +0 15:19:25 saranix: \o/ :) 15:19:29 I prefer 'disposition':enum to 'directMessage':bool 15:19:45 always enums, never bools 15:19:48 ajordan: We are going to figure out how to have clients figure out where to read from 15:20:06 ajordan: Maybe we could have clients create types of inboxes 15:20:21 extensions are going to create inboxes to post to, for instance for private messages 15:20:24 +1 from me on either using note types or flags 15:20:34 cwebber: we're most certainly going to keep supporting sub-inboxes as pump.io does that 15:20:47 cwebber: pump.io doesn't have flags though 15:21:02 topic: End to end encryption? https://github.com/w3c/activitypub/issues/225 15:21:02 cwebber: saranix changed to +0 so we have consensus 15:21:03 [brianolson] #225 Needs provisions for encrypting content for privacy 15:21:14 cwebber: Next up is end to end encryption, I'll link it on IRC 15:21:37 tantek has joined #social 15:21:40 cwebber: e2e encryption has come up multiple times. We talked about this in the working group two weeks before. We were happy about the idea 15:21:57 I'll comment on the GitHub issue that there's an informal SocialCG/SWICG consensus supporting expressing intent to target a subinbox via a flag. 15:22:03 cwebber: e2e encryption means server can't mutate or change messages 15:22:23 shouldn't it mean "read at all"? 15:22:28 cwebber: If you don't need side effects you can do like openpgp email (throwing aside ui issues) 15:22:48 cwebber: If you're sending email OpenPGP encrypted, I send an email to you the server will happily pass it along without knowing content 15:23:28 cwebber: I think majority of what you want encrypted is content, this can be done with wrapper object that has "encrypted post type" with base64 encrypted message 15:23:59 cwebber: and the user on the receiving end could decrypt and they'd be able to display in the client, which would be a json-ld object 15:24:14 q? 15:24:20 good morning #social 15:24:20 tantek: ajordan left you a message 20 hours, 20 minutes ago: you forgot to answer saranix's question about why W3C switched to GitHub issues, and from what 15:24:25 ack ajordan 15:24:26 cwebber: Main challenge would be attaching keys to things. But as this has come up multiple times and I wanted to discuss in the group 15:24:40 :) 15:25:07 q+ 15:25:14 cwebber: One place where this makes it challenging is that web apps/browsers with the existing infrastructure. Easier on mobile apps etc. 15:25:23 cwebber: Basically javascript crypto at the moment is pretty bad. 15:25:24 ack ajordan 15:25:50 ajordan: To clarify: do you think e2e crypto is difficult in web browsers is difficult or wrapping json-ld? 15:26:09 cwebber: The whole field is difficult 15:26:20 cwebber: *dragging tantek in using administrative privileges* 15:26:46 cwebber: Do people think e2e enc, despite caveats, it's a reasonable solution? Does it have problems? 15:26:53 q+ to talk about complexity regarding keys 15:26:56 q? 15:27:01 ack MMN-work 15:27:01 MMN-work, you wanted to talk about complexity regarding keys 15:27:11 scribenick: cwebber2 15:28:13 q+ 15:28:13 MMN-work: I think the complexity of crypto is hard of course, but the main problem is keeping up to date etc, for example openpgp has a terrible ui but having a nice UI won't solve things. eg, what happens if you lose your computer? if you don't have a backup key, do you lose your entire data? this problems are what happen with encryption. this is more okay with otr, because people don't really check fingerprints 15:28:40 scribenick: MMN-work 15:28:48 ack ajordan 15:29:11 q+ to say gotta do better than email, since even nerds I know can't be bothered with all the ceremony and admin crap to make / keep e2e "work" in the federated system of email 15:29:19 q+ to talk about federation 15:29:20 ajordan: So given there are a lot of userworld problems here. Losing your device, things that don't work. How do you follow someone in e2e enc etc? 15:29:42 q+ to comment on being unqualified to weigh in, and so leaning towards leaving it to extensions 15:29:47 ajordan++ self-hosting as the path forward for privacy 15:29:47 ajordan has 8 karma 15:29:49 q? 15:29:54 ack tantek 15:29:54 tantek, you wanted to say gotta do better than email, since even nerds I know can't be bothered with all the ceremony and admin crap to make / keep e2e "work" in the federated 15:29:55 ajordan: Something that's been mentioned in WG or maybe on IRC. Issues here are too complex, 15:29:58 ... system of email 15:30:08 q+ 15:30:36 present+ 15:30:41 tantek: the only point I wanted to make is that I think it's super hard and has a massive failure example in the only federated system that people tried this in (which is email) where not even nerdy nerds don't bother with all the crap to make it work 15:30:58 tantek++ 15:30:58 tantek has 59 karma in this channel (347 overall) 15:30:58 tantek: one thing to note is that riot/matrix is attempting to tackle this problem 15:31:01 x1000 15:31:11 q+ 15:31:19 tantek: I don't have particularly high hopes for any other group to solve it, especially in a more complex environment like the social web 15:31:43 q+ 15:32:03 ack nightpool 15:32:03 nightpool, you wanted to talk about federation 15:32:10 tantek: It's a hard problem but I am unsure how much more time we should spend on this. I _want_ e2e encryption but wishes don't make it so. Solve it for the simpler case email first, then solve it for this more complex scenario 15:32:35 nightpool: What we've seen is people organise into their own social groups that have their own trust. 15:33:03 nightpool: People organise into small groups so privacy is essentially assured ("I know my admin") 15:33:23 I think email is more of a problem because of the keyservers question. We don't exactly have that problem because we are bootstrapping from social "connections" where this information can be exchanged (plus webfinger, etc.) 15:33:31 FWIW the UX oddities of Mumble are more than worth the extremely clear audio. It's so much nicer, almost has a calming effect compared to any other telcon service. People sound actually human. 15:33:39 ack geppy 15:33:39 geppy, you wanted to comment on being unqualified to weigh in, and so leaning towards leaving it to extensions 15:33:51 nightpool: We are not necessarily the people here who are qualified to comment on proposed e2e encryption scheme 15:34:02 this is where extensions should be done 15:34:09 geppy: I suggest making it possible for this to be an extension 15:34:24 ack astronouth7303 15:34:26 +0 on e2e: I recognize that it is a highly-wanted feature, i'm not sold it can be done in ActivityPub while maintaining desired privacy and without breaking ActivityPub. 15:34:27 cwebber: This was not suggested to be put into the spec but rather as an extension 15:34:30 ack astronouth 15:34:33 I think an outline for what an extension's goals are is appropriate thing for this group to do... even if we don't have the implementation expertise 15:34:45 cwebber2: ^^ 15:35:11 astronouth7303: "+0 on e2e: I recognize that it is a highly-wanted feature, i'm not sold it can be done in ActivityPub while maintaining desired privacy and without breaking ActivityPub" 15:35:15 :P 15:35:24 q? 15:35:26 ack cwebber 15:36:01 q+ to clarify "an extension [to be designed later by experts]" versus "an extension [like this]" 15:36:03 cwebber: There are two things I want to say. First, this is a hard thing to do correctly. I'm sure we all know this comes up all the time - people want e2e encryption so I wanted to discuss it 15:36:09 q+ 15:36:21 no no, neither Signal nor Telegram are federated 15:36:28 incomparable to email sorry 15:36:37 that's what i was going to say :) 15:36:41 cwebber: Signal and Telegram seem to be doing much better than email with e2e encryption. Maybe explicitly designed systems it could be done better, but it would have to be tried. But I share skepticism of many people in this group. 15:36:42 I mean, iMessage does great e2e encryption :P 15:36:43 tantek: cwebber2's point is that the UX is better 15:36:48 definitely valid criticism tho 15:36:57 UX for federated e2e is MUCH harder than silo e2e 15:37:13 tantek++ 15:37:14 silo e2e can conflate all key management issues etc. and make that transparent to users 15:37:17 ack aaronpk 15:37:36 cwebber: If people are very interested in trying it. Having a wrapper with encryption type as property would solve better than gobbledigook as in OTR on XMPP etc. 15:38:07 TBH, AP should have clear definition of what is security before the ultimate security feature (=e2e) is even discussed :) 15:38:17 jaywink++ 15:38:17 jaywink has 3 karma 15:38:18 it's good to set the UX bar as high as iMessage/Signal/Telegram, HOWEVER, it doesn't mean those are proofs of concept of how to do federated UX 15:38:18 ^^ 15:38:23 aaronpk: Signal and Telegram solve this by not being federated because they handle key management. So we can't say "let's do that" 15:38:23 jaywink++ 15:38:24 jaywink has 4 karma 15:39:07 aaronpk: iMessage is coordinating the keys, so when you get new device they distribute the keys etc. So you're fetching the keys from centralised service. It works but it's not federated. 15:39:37 aaronpk++ 15:39:37 aaronpk has 88 karma in this channel (1341 overall) 15:39:43 q? 15:39:46 key management is definitely the right frame here 15:39:47 aaronpk++ the key challenge is key management 15:39:47 aaronpk has 89 karma in this channel (1342 overall) 15:39:50 aaronpk: We should handle it as a key management problem, not an encryption problem. 15:39:52 so to speak ;) 15:40:11 q+ to scope 15:40:16 aaronpk++ 15:40:16 aaronpk has 90 karma in this channel (1343 overall) 15:40:21 ack geppy 15:40:21 geppy, you wanted to clarify "an extension [to be designed later by experts]" versus "an extension [like this]" 15:40:47 ack ajordan 15:40:47 geppy: I don't feel qualified to weigh in on any aspect, extension or not. 15:41:07 https://en.wikipedia.org/wiki/OMEMO 15:41:27 ajordan: Since we're talking about OTR, Signal etc, an example of federated encryption system that works is OMEMO 15:42:15 ajordan: I recommend looking into OMEMO for design choices such as "each device has a key" instead of each user which makes it easier to use. 15:42:20 Matrix has federated e2e 15:42:22 q? 15:42:28 good point wilkie 15:42:56 ajordan: Another thing that makes it work is the fact that XMPP has publish/subscribe which makes it easy to update and basically coordinate device lists so you can easily see which clients the user has 15:43:00 yeah I mentioned that a bit back but it got lost in the scrollback I think. it also has this per-client key thing 15:43:09 see https://matrix.org and https://matrix.org/docs/guides/e2e_implementation.html 15:43:09 ajordan: And based on this, it's possible to activate OMEMO encryption 15:43:14 Welcome to Matrix 15:43:14 An open network for secure, decentralized communication. 15:43:14 Learn More 15:43:14 ... 15:43:16 Matrix developed this Olm library, which might be of some inspiration: https://github.com/matrix-org/olm 15:43:17 [matrix-org] olm: An implementation of the Double Ratchet cryptographic ratchet in C++/C 15:43:21 q+ to OMEMO history etc. 15:44:02 ajordan: There are still issues that clients won't say "I don't support this" and ActivityPub maybe doesn't have this signalling and primitives for devices. 15:44:18 q? 15:44:22 ack nightpool 15:44:22 nightpool, you wanted to scope 15:44:24 cwebber: Matrix has end to end encryption 15:44:45 I'm going ayway for a moment 15:44:48 (that last scribe of me was relaying what wilkie said 15:44:49 ) 15:44:54 get geppy 15:45:05 s/activate OMEMO encryption/activate OMEMO encryption automatically/ 15:45:06 scribenick geppy 15:45:14 scribenick: geppy 15:45:17 !tell saranix before github issues, w3c issues were kept in a variety of disparate systems, some with very poor UX (which meant people didn't use them much in practice, or only a small subset with lots of time to spend used them, another form of indirect exclusion). disparate systems like W3C bugzilla, W3C "tracker", w3c wiki pages, documents in w3c CVS, etc. Individual WGs started switching to github because it was far more accessible/usable (thus inclusive) to 15:45:17 Ok, I'll tell them that when I see them next 15:45:18 more people than *any* of those disparate systems. 15:45:21 ack MMN-work 15:45:21 MMN-work, you wanted to OMEMO history etc. 15:45:24 MMN-work is stepping away for a moment 15:46:03 my stuff didn't get scribed 15:46:06 cwebber: do we want to say we've said all we have to say? we've had a useful conversation pointing out relevant prior art 15:46:09 let's capture OMEMO and Matrix as examples to read & review before continuing discussion 15:46:11 sorry, nightpool 15:46:11 I'll re-do it here 15:46:17 q? 15:46:29 what's the issue # / URL for tracking this? 15:46:50 We should make sure to narrow our scope: if we want to implement e2e as an extension, we should focus first on the scope of direct messages, with 1 user talking to 1 other user 15:46:59 basically chats 15:47:16 ajordan: if anyone disagrees, feel free to speak up. but it seems the general consensus is that this is an extremely complex issue that we may not be able to solve *at all*. We may have more basic issues we need to resolve, e.g. direct messages 15:47:25 doesn't matter how complex it is, somebody is going to do it... it is going to be important to outline the goals of it and why it is hard? 15:48:10 cwebber2: proposal: E2E is interesting and worth exploring in the future, but not the primary focus of *this* group. 15:48:17 we don't seem to have an issue for this on https://github.com/swicg/general/issues 15:48:18 cwebber2: I would make an even stronger proposal 15:48:35 +1 15:48:43 in that this group does not have the resources or expertise to qualify an e2e system. 15:49:15 aaronpk: I'd suggest that we should review the prior art of OMEMO and Matrix before talking about this again. 15:49:15 +1 out of scope for the main SocialCG (the "play in the corner" solution) 15:49:33 yes, what cwebber2 is saying 15:49:47 cwebber2: It may be useful to talk about this in order to lay the groundwork. Maybe write up a report about issues we've identified. Cochairs? 15:49:50 +1 revisit after everyone has read the material 15:49:51 saranix: tantek left you a message 4 minutes ago: before github issues, w3c issues were kept in a variety of disparate systems, some with very poor UX (which meant people didn't use them much in practice, or only a small subset with lots of time to spend used them, another form of indirect exclusion). disparate systems like W3C bugzilla, W3C "tracker", w3c wiki pages, documents in w3c CVS, etc. Individual WGs started switching to github because it was far ... 15:49:52 ... more accessible/usable (thus inclus[CUT] 15:50:05 q? 15:50:14 I'd be willing to look into this and write up some unofficial notes for my own domain 15:51:05 MMN-work++ for scribing earlier 15:51:05 mmn-work has 2 karma 15:51:09 informal proposal: e2e is important but we don't have the expertise / experience to do it right now, we're interested in hearing more research about it, but we don't have the bandwidth to make it take up our primary work right now 15:51:14 +1 15:51:16 +1 15:51:17 +1 15:51:17 +1 15:51:18 +1 15:51:20 +1 15:51:20 +1 15:51:21 +1 15:51:32 +1 15:51:46 tantek, aaronpk: https://github.com/w3c/activitypub/issues/225 15:51:46 [brianolson] #225 Needs provisions for encrypting content for privacy 15:51:58 cwebber2: I haven't seen so many +1s at once in a while! Informally resolved. 15:52:01 I need the next item on the agenda... where do we write these notes heh because I can write something up 15:52:09 not so many +1s so fast anyway :) 15:52:27 topic: Authenticated/private WebSub subscriptions 15:52:28 +1 15:52:30 :P 15:52:37 +1 (to cwebber2's proposal) 15:52:55 +1 15:54:41 scribenick: cwebber2 15:55:29 aaronpk: github supposedly implemented websub, but it turns out not exactly, since they require authenticating via an api key, which breaks compatibility but for a reason presumably they need. wondering if anyone has heard of other groups doing this or are interested in exploring it 15:55:43 q? 15:55:49 !tell saranix re: @user - did not happen because of Twitter marketing, rather people were already using @-name references on Twitter *before* Twitter acknowledged it, linked them, and made them official. @-name refs predate twitter on various other bbs or silos (e.g. have seen on Flickr too) 15:55:49 Ok, I'll tell them that when I see them next 15:56:18 aaronpk: I also know that mastodon has done interesting things with PuSH / websub to do private feeds, wonder if there are things we can learn from them 15:56:20 geppy1 has joined #social 15:56:41 nightpool: mastodon seems to hook WebSub into Salmon somehow, requiring approval for follow requests 15:56:47 nightpool: yes, mastodon hooks up pubsubhubbub with salmon in a way I'm not familiar with, where person following needs to approve it 15:56:53 scribenick: geppy1 15:57:03 q? 15:57:22 cwebber2: I think what Mastodon does is they check the hostname of the websub target url, and if noone on that host is following that person, that subscription only gets public posts 15:57:29 agenda+ this CG is skewed towards ActivityPub people 15:57:51 (aaronpk? ajordan?): I think unlike e2e this is something we can actually make progress on 15:58:10 s/(aaronpk? ajordan?)/aaronpk/ 15:58:10 ajordan: the agenda is skewed that way but doesn't have to be 15:58:20 geppy++ 15:58:20 geppy has 1 karma 15:58:20 nightpool: That's how they distribute private messages, but it's also how they handle follow requests if your account is "locked". 15:58:26 ajordan: anyone can add topics, and should 15:58:33 cwebber2: that's what I'm saying 15:58:35 q? 15:58:36 I think this is really interesting, but I'll have to go back and see what I missed 15:58:45 +1 to ajordan's point 15:58:49 most people here are interested in AP, I'd like to bring more IndieWeb people in here 15:59:26 cwebber2: We have two agenda items left, do we want to do that? 15:59:31 Sorry, I used to know how the system works but it's been a few months since I touched that part of the code 15:59:33 PROPOSAL: extend the group for 15 minutes 15:59:36 +1 15:59:36 +1 15:59:37 +1 15:59:38 +1 15:59:38 +1 15:59:39 +1 15:59:41 +1 15:59:49 +1 can actually make it today because #css is pushed to 16:00 PDT! 15:59:53 +1 15:59:54 :) 15:59:56 \o/ 16:00:08 (proposal succeeds) 16:00:30 cwebber2: next topic is where extension proposals should go (ActivityPub organization, SWICG repo, ...) 16:00:59 cwebber2: long term I'm not sure putting it on /activitypub makes sense, especially once it goes to CR. Can someone with more W3C experience weigh in? 16:01:12 q? 16:01:14 cwebber2: do tantek or aaronpk have any thoughts on this? 16:01:35 q+ to mention rel="" 16:01:45 there is an "i'm thinking" emoji, don't know about emoticons 16:01:46 🤔 16:02:31 tantek: extensions are a weird thing in the W3C space in that I don't know of a consistent pattern, despite being involved in W3C for years. 16:02:42 tantek: I think if we come up with something that sounds reasonable it's likely to be okay 16:03:15 q+ 16:03:26 q+ 16:03:57 Has anyone recently been able to sign up for a wiki account? 16:04:08 q? 16:04:08 q+ 16:04:13 ack geppy 16:04:13 geppy, you wanted to mention rel="" 16:04:16 scribenick: MMN-work 16:04:40 geppy: [silence] 16:04:55 nightpool: wiki logins are a disaster, see https://socialwg.indiewebcamp.com/irc/social/2017-06-07/line/1496821239733 16:04:56 [ajordan] astronouth7303: try setting your password to 16 characters, alphanumeric only 16:05:02 (and following messages) 16:05:04 geppy, we assume you are typing :) 16:05:23 geppy left the server 16:05:31 q+ geppy 16:05:32 ajordan: I have a concrete proposal. 16:05:32 geppy, keep typing, I will relay you when you're done... oh, or maybe you dropped out 16:05:39 ack ajordan 16:06:45 ajordan: If we want to write a "spec" we can create another repository under SWICG we can have an issue tracker for that extension specifically 16:06:57 geppy1 has joined #social 16:06:59 geppy: I'd refer to I think the HTML `link` tag's `rel` property is defined as being extended on microformats.org, as well as if there's a microformat spec (can't remember) I think it also says "go look at the external microformats wiki for extensions". [sorry, got disconnected while saying this earlier] 16:07:11 Sorry, got disconnected again. :/ 16:07:16 cwebber: We could record, accept PRs etc, put their drafts into text. That sounds good to me. 16:07:27 *refer*, not *prefer* 16:07:54 geppy: I'd prefer to think the HTML `link` tag's `rel` property is defined as being extended on microformats.org, as well as if there's a microformat spec (can't remember) I think it also says "go look at the external microformats wiki for extensions". [sorry, got disconnected while saying this earlier] 16:08:01 ack geppy 16:08:22 (MMN-work: anything someone says in IRC is automatically recorded as part of the minutes, just FYI) 16:08:26 cwebber: I don't think the same workflow applies to us. It is useful to look at what other attached parts of our (web/w3c/social) space 16:08:34 ack nightpool 16:08:35 cwebber: ...are doing 16:09:16 nightpool: My proposal is basically the same as ajordan's. The major difference is that we have a organisation namespace so many extensions could live in their own repos. With ActivityPub repo we only have that single repo to work with. 16:09:17 PROPOSED: Create an activitypub-extensions repo under the SWICG GitHub org in order to discuss AP extensions. Move existing "postponed (revisit in future effort)" discussions there. Create a separate repository if we want to actually write out some spec text for an extension. 16:09:29 +1 16:09:32 +1 16:09:35 +1 16:09:38 +1 16:09:41 nightpool: Also we should rename SWICG to SocialCG considering the resolution on the last meeting 16:09:42 what about https://www.w3.org/wiki/ActivityPub_extensions 16:09:51