11:27:22 RRSAgent has joined #social 11:27:22 logging to https://www.w3.org/2020/11/07-social-irc 12:22:00 ilmu has joined #social 15:55:32 RRSAgent, make logs public 15:55:54 Zakim, start meeting 15:55:54 RRSAgent, make logs Public 15:55:55 please title this meeting ("meeting: ..."), rhiaro 15:56:19 Meeting: Social Web Incubator CG 15:57:46 manu has joined #social 15:59:14 Chair: cwebber 16:00:00 we are on mumble 16:05:19 vpzom[m] has joined #social 16:05:21 I'm on 1.3.3 and it works fine, but maybe ubuntu has it configured differently 16:07:01 scribenick: manu 16:07:10 cwebber2 has joined #social 16:07:16 chair: cwebber2 16:07:22 Meeting: Social Web Community Group 16:07:46 present: cwebber, nightpool, dmitriz, rhiaro, manu, vpzom 16:07:48 dmitriz has joined #social 16:07:55 present+ sebastian 16:08:13 present+ 16:08:44 cwebber2: Here's the agenda... 16:08:53 https://socialhub.activitypub.rocks/t/socialcg-meeting-on-november-7th-16-00-utc/1106 16:09:14 don't 16:09:14 rrsagent, make logs public 16:09:16 do that 16:09:35 sebastian: Would like to thank CCG for giving the call a home. 16:09:48 cwebber2: We have a number of items -- let's start with alsoKnownAs 16:10:44 /kick Zakim 16:11:25 rhiaro, I have no authority to do so, but this nickspamming is disturbing 16:12:25 topic: Officially make alsoKnownAs part of the AS2 vocabulary 3 16:14:45 rhiaro, it is fine :) 16:15:18 cwebber2: Let's start with alsoKnownAs 16:15:54 cwebber2: Basically, with this topic - I think Mastodon introduced alsoKnownAs term into Activity Streams namespace, has a well-followed pattern as to how it's used, not a part of AS. 16:16:00 cwebber2: DID WG would like to make use of it 16:16:18 cwebber2: So, we it would be great if we could, as CG, to ratify as an extension -- could do this in the meeting. 16:16:22 definition in DID Core: https://w3c.github.io/did-core/#alsoknownas 16:16:34 pull request to add it as an AS2 extension: https://github.com/w3c/activitystreams/pull/512 16:16:44 manu: yes, basically we'd like to see alsoKnownAs ratified in the same way that the AS2 community is using... mastodon and anyone else using it in this space 16:16:56 cwebber2: Yes, that makes sense. 16:16:57 q? 16:17:05 [rhiaro] #512 Extension: alsoKnownAs from DID Core 16:17:11 cwebber2: Let's open it up for discussion -- feel like this could be an easy win, where we just vote and agree to do it. 16:17:22 cwebber2: Just wanting to wait to see if there is any input? 16:17:30 q+ to talk about the current definition 16:17:31 +1 for alsoKnownAs 16:17:41 +1 for alsoKnownAs 16:17:45 manu: is there concrete spectext? 16:17:50 q+ to answer manu's question 16:17:53 ack nightpool[m] 16:17:53 nightpool[m], you wanted to talk about the current definition 16:18:00 nightpool: Thanks Chris, I think we did some work in defining it in the wiki? 16:18:21 nightpool: I'm trying to look it up -- thought some of those early extensions in AS namespace, thought we took a swing at defining them. 16:18:25 q+ 16:18:30 https://socialhub.activitypub.rocks/t/defining-alsoknownas/907 16:18:31 nightpool: I know I made it for just one of them... 16:18:49 nightpool: Let me look at my gist. 16:19:02 sebastian: I think Amy mentioned the specs in social hub location. 16:19:17 nightpool: I believe Amy just linked to Mastodon docs. 16:19:26 cwebber2: We did it for sensitive at least. 16:19:30 ack rhiaro 16:19:30 rhiaro, you wanted to answer manu's question 16:19:31 ack rhiaro 16:20:17 I believe this is the discussed link https://www.w3.org/wiki/Activity_Streams_extensions 16:20:26 https://w3c.github.io/did-core/#alsoknownas 16:20:27 rhiaro: I found that when I was looking this up originally, definition in Mastodon docs, write up a definition that made sense in DID WG perspective as well as make sense in Mastodon perspective. Put it on Social Hub forum to see if that made sense to folks. 16:20:33 looks like it covers as:Hashtag, as:sensitive, as:manuallyApprovesFollowers 16:20:50 rhiaro: What I've done is make a PR on activity streams NS to add it as an extension... the concrete thing we should vote on is to determine if that PR should go in. 16:21:03 rhiaro: Peopel from Activity Pub side or DID side change that before DID Core goes to CR. 16:21:15 rhiaro: Might be worth talking about how to coordinate both groups. 16:21:23 pr: https://github.com/w3c/activitystreams/pull/512 16:21:25 Thanks Chris, i'm satisfied there isn't any unknown prior art here we should be looking at 16:21:29 q+ to suggest we do this iteratively 16:21:29 [rhiaro] #512 Extension: alsoKnownAs from DID Core 16:21:34 cwebber2: link in IRC 16:21:35 I was thinking of the #sensitive property primarily 16:21:41 cwebber2: That has spec text definition, reading it out loud 16:22:01 cwebber2: alsoKnownAs 16:22:01 The value of alsoKnownAs MUST be a list where each item in the list is a URI conforming to [RFC3986]. 16:22:01 This relationship is a statement that the subject of this identifier is also identified by one or more other identifiers. 16:22:06 cwebber2: That feels like a clean definition to me 16:22:14 cwebber2: nightpool, does that address your understanding? 16:22:41 nightpool: Yes, in actual AS namespace, just linking to DID Core. 16:23:02 nightpool: Yes, that definition makes sense, although, I guess it's a little weird. 16:23:06 q? 16:23:14 it's deliberately as generic as possible.. 16:23:18 cwebber2: Could I ask for clarity on what's weird? 16:23:26 and also has aspects that are specific to how the DID spec is defining terms (like INFRA) 16:23:30 nightpool: Not entirely clear on DID spec, seems specific to DIDs... 16:23:39 cwebber2: Let's get to the queue, Manu might comment on that. 16:23:43 ack sl 16:24:24 sl007: My question is about how we can express alsoKnownAs in HTML layer -- like rel attribute for links? If we should propose together with this proposal a spec for a rel attribute for a link. 16:24:38 sl007: We have rel=me and nightpool pointed out that this is more like rel=alternate than rel=me. 16:24:45 Point of order: I said the opposite. 16:24:56 sl007: The rel attributes can provide alternate protocols -- 16:24:56 `url` is alternate, `alsoKownAs` is like me 16:25:08 ack manu 16:25:08 manu, you wanted to suggest we do this iteratively 16:25:20 q+ to the rel= question 16:25:27 cwebber2: two things to respond to -- subject identifier, is it did specific, then rel stuff... 16:25:57 paul has joined #social 16:26:36 manu: the first thing to let the pressure off of the decision... we might just want to agree to this iteratively. We don't have to agree to an exact definition today, we have time in the DID WG to modify it, if we can just get an agreement today that this is a good starting point we can refine, we have at least 9 months 16:27:10 q+ to talk about the DID specific bits 16:27:30 manu: second thing around nightpool's concern about talking about subject, also the "must be a list", the goal here is to share the semantics with the AS2 community. The DID spec just because of weirdness in that group has chosen to use introspect to use lists and sets and etc... so there's extra imposition on that 16:27:52 manu: I would look at that as a ratcheting down of the semantics in AS2. It's not trying to change it, it's trying to impose additional restrictions 16:28:49 manu: I think nightpool points out things that yes, you should be concerned about, but it's in no way an imposition on the AS2 spec... there's a general AS2 use, and the DID spec can help refine it without changing semantics... we hope it's more that the AS2 deinition is general and then the DID spec can put its own specific requirements for use on it 16:29:03 manu: about rel, I think that's fine, but I think that could be a separate conversation 16:30:00 rrsagent, draft minutes 16:30:00 I have made the request to generate https://www.w3.org/2020/11/07-social-minutes.html manu 16:30:01 manu: I think we need to know that this community is fine with defining alsoKnownAs, because otherwise the DID community would have to do it, and that would be a failure to standardize 16:30:11 q? 16:30:26 ack nightpool[m] 16:30:26 nightpool[m], you wanted to the rel= question 16:30:38 nightpool: Yes, wanted to confirm that I think sebastian is not in IRC -- said something that didn't get proxied. 16:30:55 q? 16:31:06 q+ to see if we can get consensus 16:31:16 `rel="http://www.w3.org/ns/activitystreams#alsoKnownAs"` is perfectly fine in HTML or even in HTTP Link header. Doesn't need to be `alsoKnownAs` 16:31:16 nightpool: I said the same thing in IRC -- alsoKnownAs is more like rel=me than rel=alternate... there might be spec work to be done there, might be good to do unification there, agree with Manu, let's take this one thing at a time. 16:31:34 * Doesn't need to be `rel="alsoKnownAs"` 16:31:58 q? 16:31:59 hence, don't have to go through IANA 16:32:02 ack rhiaro 16:32:02 rhiaro, you wanted to talk about the DID specific bits 16:32:02 nightpool: Agree with manu, let's make AS define something more general and then have DID Document refine it a bit... that's not what we have in namespace document, just a pointer to namespace definition -- we might wnat to do another draft somewhere w/ AS definition somewhere. 16:32:56 rhiaro: The way it is written, definition in DID Core spec, first paragraph, DID specific stuff, actual definition - bold italics, that's the bit that's the definition of the term that should be generic for everyone, everything else should be DID specific -- distinct block that should be generic. 16:33:42 q? 16:33:44 rhiaro: Manu said there should be general definition in AS - no definition in AS for this, and I don't think we can change AS Vocab spec, which is a REC -- don't see it happening realistically, don't see how we get another term in there. The only definition that exists is in the DID Core spec. The way extension should work could be defined elsewhere. 16:33:45 q+ 16:33:51 ack cwebber 16:33:51 cwebber, you wanted to see if we can get consensus 16:33:54 q+ to note Amy's right -- how do we want to proceed? 16:35:03 AS spec and vocab are not tied. Can add terms to AS vocab ;) 16:35:28 cwebber2: Let me start out by saying -- we had some recent conversation at ActivityPub conference - we had a broad number of implementers at ActivityPub on what SocialWebCG should do moving forward, three things people wanted 1) This meeting about extensions and when meetings are important, 2) demonstrations of what people are building -- using screensharing about what they're building, 3) putting out CG reports especially around current state of 16:35:28 extensions, both within and without AS vocabulary -- also about known patterns of deploying ActivityPub. 16:35:48 And? this is about adding a term to AS2 vocab/context, no? 16:35:56 spec doesn't need an update 16:36:09 Just as we added ldp:inbox to LDP vocab... remember? 16:36:26 q? 16:36:30 cwebber2: First of two CG extensions - maybe we can at this time, not chartered to put out spec document, but can put out CG document... feels like good place to get consensus in the group -- excellent set of first things to add to that document. Even if it's not officially published thing, officially published in DID Spec, still useful to make record of this. I'd love to hear what Manu thinks of that. 16:36:38 cwebber2: I have a suggestion of the path forward. 16:36:41 q+ to defer to Amy :P 16:36:54 cwebber2: Feels like we're going to have the followign things happen: 16:37:13 cwebber2: 1) Everyone agrees that we would like to get alsoKnownAs in more general form as AS extension and have this group move forward with that. 16:37:25 in the vocab 16:37:35 cwebber2: 2) We don't need to have the exact phrasing right now, we just need to get agreement that this is the right definition in AS. 16:37:38 vocab describes itself 16:38:05 cwebber2: 3) The rel question is interesting, but does not need to be solved immediately, given that there are two communities using alsoKnownAs, and that's not going to change given what we know. 16:38:18 cwebber2: If we generally agree with that, we might be able to get consensus. 16:38:39 q? 16:38:44 ack manu 16:38:44 manu, you wanted to note Amy's right -- how do we want to proceed? and to defer to Amy :P 16:39:03 manu: yes I agree with that, though I defer completely to rhiaro because she's done the real work 16:39:07 q+ 16:39:16 have W3C conneg the AS2 vocab to HTML(+RDFa) .. or create one eg. see https://www.w3.org/ns/ldp in text/html 16:39:19 manu: but I think your 1, 2, 3 is spot on. if we can get a proposal forward for some of that stuff, that would be great 16:39:22 q? 16:39:27 q+ 16:39:35 ack sl 16:40:20 what's the extension URL? 16:40:43 sl007: I'm just trying to generalize my question - as implementer of ActivityPub, about rel thing - if my software visits any website and wants to know what profiles are active, I'd check each rel=me link, basically. It's a "yes/no" question -- should we have an extra rel attribute where I can propose rel to IANA, for example, what AaronP did for micropub profile? Do we need something for ActivityPub? 16:41:04 cwebber2: That sounds like a worthwhile thing to investigate, would you be willing to have us take that on, could you take leadership on that? 16:41:16 cwebber2: Do you agree that it is not a blocker for this, but can be complimentary. 16:41:33 sl007: Yes, exactly -- wanted to know your thinking, but would then take lead and talk w/ Aaron Parecki on Micropub. 16:41:54 q? 16:42:00 cwebber2: Let's make this a topic for next meeting? Sounds like you and nightpool have given it a lot of thought 16:42:03 ack rhiaro 16:42:17 rhiaro: What you put in IRC, the 1-2-3 points sounds right. 16:42:54 rhiaro: CG Report, good idea, wondering how we do it -- worrying about it being a bottleneck for the DID Work, can we do it in a way that things are decoupled? Will SocialCG stuff move quickly? One document for each extension that's ratified? 16:43:04 rhiaro: Once CG Report is published, can it be updated? 16:43:10 rhiaro: Thoughts on the suggestion? 16:43:14 (would like to note for posterity that existing implementations use Content-Type/Accept negotiation to do this, not HTML rels. and I think will probably want to continue to do this for the forseeable future) 16:43:38 rhiaro: Starting w/ generic part of definition in DID Spec, AS points to it until something more appropriate per the definition points to something better. 16:43:39 (sorry, WRT sl007 (IRC)'s proposal, not the other discussion) 16:43:42 cwebber2: That soudns really good to me. 16:44:03 +1 complementary 16:44:25 cwebber2: Wrt. CG report, don't want it to be a blocker. If it's a blocker, I'll walk back from it -- don't want it to block. CG work should be a complimentary publication, mostly about capturing current understanding and knowledge of the community... closer to indieweb on living spec/living document. 16:44:55 cwebber2: General idea - create git repo with spec, encourage contributions, one about current practices, one about extensions, get leadership in Social Web communtiy to start working on that. 16:45:01 cwebber2: does that sound acceptable? 16:45:33 rhiaro: Yes, don't want to end up backed up into a corner - DID spec needs it's own defintion, term has to appear in AS namespace and JSON-LD context, I think we're good. 16:45:44 q? 16:45:44 manu confirms that he believes what rhiaro said to be correct. 16:46:03 cwebber2: rhiaro, do you want to try to make a proposal? 16:46:07 rhiaro: gimme two seconds. 16:47:01 q+ 16:47:16 hehe 16:47:21 ack sl 16:47:34 sl007: Just wanted to see if pukkamustard is here? Intro on fediverse enhancement proposals? 16:47:59 I haven't seen them on jitsi but I'm very interested in that 16:48:01 the FEP 16:48:14 cwebber2: /me +1 to both proposals. 16:48:29 q+ 16:48:43 s/cwebber2: \/me/\/me/ 16:49:11 PROPOSAL: we accept the alsoKnownAs definition in the DID Core spec ("This relationship is a statement that the subject of this identifier is also identified by one or more other identifiers. ") as a starting point that can be iterated on with the participation of both the DID and SocialCG communities 16:49:31 s/PROPOSAL: we accept the alsoKnownAs definition in the DID Core spec ("This relationship is a statement that the subject of this identifier is also identified by one or more other identifiers. ") as a starting point that can be iterated on with the participation of both the DID and SocialCG communities// 16:49:33 ack nightpool[m] 16:49:43 Amy makes two proposals. 16:49:55 nightpool: I thought we wanted a more general definition that was unrelated to DID Core spec? 16:50:13 nightpool: That doesn't seem like that's here in the proposals... but I guess DID Spec wants something normative. 16:50:35 cwebber2: You're concerned because of language -- subject of this identifier and list thing is problematic? 16:50:57 cwebber2: This permits us to start iterating because of "as a starting point" 16:51:19 q+ 16:51:34 cwebber2: I don't think subject and identifier are meant to be specific to DIDs... it's not meant to be DID specific, goal of starting point is to iterate. 16:51:43 ack rhiaro 16:51:43 cwebber2: Amy does that match your thoughts? 16:51:53 rhiaro: Yes, exactly -- identifier and subject are meant to be general... 16:52:27 rhiaro: The subject could be an Activity Pub profile URl -- supposed to be general/generic language... relationship is alsoKnownAs -- ANY identifiers, HTTP URLs, DIDs, etc. 16:53:05 nightpool: Yes, that makes sense to me... seems like there was some sort of disconnect -- define in AS and then nail it down in DID Core -- more conceptual sense to me. 16:53:40 cwebber2: Ah, one more thing -- DID Core document contains same definition in CG Report, but it will also add some additional DID specific restrictions... will contain AS thing, and within DID Spec may put more requirements on top. 16:53:44 cwebber2: Does that make sense? 16:53:56 nightpool: Yes, that makes sense, and we don't want CG Report to be a blocker on DID WG. 16:54:04 cwebber2: Is that aligned, rhiaro? 16:54:40 rhiaro: Yes, DID Core one should be equal or more constrained of AS definition. They shouldn't ever be in conflict, and I don't think it's likely that AS would ever become incompatible w/ DID Core, it should be the more generic one, DID Core will be more specific. 16:55:07 sl0071 has joined #social 16:55:13 rhiaro: About defining in AS -- where, what document? We can't change the spec, don't want there to be non-normative AS document that DID Core points to or depends on that we can't depend on from W3C Process perspective. 16:55:33 cwebber2: It sounds like nightpool and rhiaro are in agreement, nightpool do you feel like that answered your questions? 16:55:57 nightpool: Yes, I think we can move forward on this basis -- we can move forward asynchronously... like -- actors, do those make sense... can make it fairly general. 16:56:17 cwebber2: Within AS usage -- could specifically mean this -- ok... let's get to the vote. 16:56:21 PROPOSAL: we accept the alsoKnownAs definition in the DID Core spec ("This relationship is a statement that the subject of this identifier is also identified by one or more other identifiers. ") as a starting point that can be iterated on with the participation of both the DID and SocialCG communities 16:56:23 cwebber2: Let's get votes in.. 16:56:28 manu: +1 16:56:32 +1 16:56:32 +1 16:56:34 +1 16:56:36 +1 16:57:00 +1 16:57:11 not sure if I should have voting rights :9 16:57:15 +1 16:57:22 I am 16:57:43 +1 16:57:44 RESOLVED: we accept the alsoKnownAs definition in the DID Core spec ("This relationship is a statement that the subject of this identifier is also identified by one or more other identifiers. ") as a starting point that can be iterated on with the participation of both the DID and SocialCG communities 16:57:50 PROPOSAL: we merge PR 512 on the AS2 namespace to add alsoKnownAs to the jsonld context, and point to the human readable normative definition in DID Core 16:58:03 manu: +1 16:58:04 +1 16:58:06 +1 16:58:08 +1 16:58:11 +1 16:58:12 i have one comment on the PR but it's not blocking 16:58:13 +1 16:58:14 +1 16:58:47 RESOLVED: we merge PR 512 on the AS2 namespace to add alsoKnownAs to the jsonld context, and point to the human readable normative definition in DID Core 16:59:12 cwebber2: Yaay, the Social CG did a thing! This has been a productive meeting from my perspective. I think we're in a good starting place. 16:59:26 cwebber2: Agreeign to merge that PR, that's a huge step there... we didn't get to all of our agenda items. 16:59:39 cwebber2: Some of these other things might be easier now that we've had progress on alsoKnownAs -- 16:59:43 dmitriz: When is the next meeting? 17:00:15 cwebber2: Good question -- happy to do one in as soon as two weeks ... but might be too close to the November holidays? Could do next week, non-holiday nearby next week? 17:00:21 +1 to either next week or the next nearby 17:00:28 cwebber2: Next week or week of 21st? 17:00:47 yeyyyy 17:00:49 cwebber2: Ok, let's do this next week then. 17:01:00 cwebber2: I'll post on social hub. 17:01:05 Thanks for chairing cwebber2! 17:01:23 manu++ 17:01:23 manu has 1 karma over the last year 17:01:31 what only one karma 17:01:33 manu++ 17:01:33 manu has 2 karma over the last year 17:01:38 lol 17:01:41 RRSAgent, make logs public 17:01:57 Zakim, end meeting 17:01:57 As of this point the attendees have been cwebber, nightpool, dmitriz, rhiaro, manu, vpzom, sebastian 17:01:58 cwebber2: Great, congrats everyone on being productive during this meeting, take care! 17:01:59 RRSAgent, please draft minutes 17:01:59 I have made the request to generate https://www.w3.org/2020/11/07-social-minutes.html Zakim 17:02:03 I am happy to have been of service, rhiaro; please remember to excuse RRSAgent. Goodbye 17:02:07 Zakim has left #social 17:02:10 manu: the karma markets are really hot right now 17:02:24 rhiaro++ for bringing us the first useful #social meeting topic in months! :D 17:02:24 rhiaro has 1 karma in this channel over the last year (4 in all channels) 17:02:45 rhiaro has 2 karma in this channel over the last year (5 in all channels) 17:02:54 I hear that karma default swaps might cause problems eventually but for right now I'm doing good deeds like mad for the karmacoins 17:03:01 cwebber2: do you have merge rights on that namespace repo? 17:03:17 rhiaro: I don't think so, I think Evan does though 17:03:20 let me look tho 17:03:36 manu: I'm assuming we can ask ivan really nicely to update the namespace doc on w3c servers when it's ready.. 17:03:42 present+ paul 17:03:58 rhiaro: I expect so :) 17:04:41 rhiaro: I can report back to DID WG -- unless you want to do that? 17:04:47 rhiaro: well I see a "merge pull request" button 17:04:48 thx, I'm a total irc noob 17:04:49 so I guess I do 17:05:01 paul: you're doing great :) 17:05:17 Also, these IRC bots we're using are all sorts of arcane magic. 17:05:36 paul -- https://www.w3.org/2002/03/RRSAgent 17:05:36 paul has -1 karma over the last year 17:05:39 oh no! 17:05:42 what have I done!? 17:05:44 paul++ 17:05:46 paul++ 17:05:46 too much karma! 17:05:51 gasps. 17:06:01 didn't hurt 17:06:17 I've sullied paul's name... my apologies, paul. 17:07:12 paul ~~ https://www.w3.org/2001/12/zakim-irc-bot.html 17:07:42 manu, I think there's an open PR on the did-spec-registries for adding it to the did core jsonld context. I can update that to say we're resolved, and update again when the AS2 context is actually updated? Don't think we have any other open issue for this at the moment 17:08:26 rhiaro: that's fine -- was trying to figure out how to signal more strongly to DID WG that progress has been made here... like, via email to mailing list. 17:08:39 (helps demonstrate broad review/collaboration) 17:08:40 +1 emailing 17:08:46 manu, happy for you to email the list if you want.. hopefully we have a permalink to this resolution.. I'll grab it 17:09:00 https://www.w3.org/2020/11/07-social-minutes.html#ResolutionSummary yessss the arcane magic works so well 17:09:06 [pol, sorry] : you stare at a tv screen for days and then they announce it during the socialcg meeting … 17:10:27 hahahahah 17:10:31 yeah I just heard 17:11:06 this work here was more historical IMO ;) 17:11:30 totally paul, totally 17:11:31 lol true 17:13:39 rhiaro: I get so many github notifications I don't see them often, so let me know when you and nightpool have resolved the bit about how to link to external documents 17:13:44 once that's odne I think we can merge the PR 17:13:51 so ping me if I don't see it 17:16:35 As another follow-up here, I wrote down what I would expect a "activitystreams-specific" definition to look like, based on the ways this is used on the fediverse: https://socialhub.activitypub.rocks/t/defining-alsoknownas/907/16?u=nightpool 17:16:42 cwebber2: will do. I also have the merge button actually, but someone else should merge it since it's my PR 17:18:31 I’m thinking of this definition as kind of a “starting point” from the other side, so we can figure out what the generic definition might look like by unifying these two ideas and hopefully create something that doesn't feel too DID-focused. Please let me know if you have any feedback! 17:18:48 (It's also at the socialcg link I pasted above) 17:19:17 let me know if that's helpful! 17:20:10 thanks nightpool! 17:20:12 thanks nightpool[m] that's great. Obviously AP-specific, so good to see it written out so we can find the common parts 17:24:21 nightpool - great definition / starting point. My main question reading it is - from the AP side, does it require (or recommend) the two-way link? (as in, both Actor profiles have to have corresponding links?) 17:26:19 dmitriz: the way mastodon uses it afaik is two way link is not required, but *if* there's a two way link you can do mor ethings with it, like profile migration 17:27:58 ahhh got it 17:28:16 one, that's really cool. (that it's progressive like that). and, worth mentioning in that definition 17:30:15 Yeah, i was a little torn on whether to emphasize that more or less—AIUI in mastodon there's no functionality until you get to a two-way link, and it might make sense to make it required, since we'd want to avoid the misleading/abusive case where someone could trick a implementation that only thinks only about one-way links for the purposes of harassment/etc 17:30:17 thoughts? 17:34:51 Ah, I may have been slightly imprecise—mastodon processes one way links for the purpose of providing the linked-to account the opportunity to confirm the links easily in the settings menu. 17:35:34 nightpool - yeah, I definitely think it's worth explicitly calling out both cases. the one-way properties, and the two-way security properties 17:37:11 it's basically like, it can be one way for whatever reason, but you MUST NOT trust it for anything unless it's two-way 17:38:54 yep, definitely! that was the needle I was trying to thread with my definition, will update to make it stronger + clearer 17:41:42 nightpool[m]: see the note following the alsoKnownAs dfn in DID Core - https://w3c.github.io/did-core/#dfn-alsoknownas - it's about that 17:50:25 hey nightpool[m], I pushed another commit to change the section name (and also linked to the resolution, I think it's good practice to do that going forward) 17:57:06 thanks! looking now 17:58:02 I also really like the way that note explains it—the presence of the also known as assertion should not be confused for proof of the assertion 18:03:19 rhiaro: changes LGTM! I'm ambivalent on linking to the resolution in the namespace itself vs trusting Github's record of PRs or the git commit message to contain it, since parties interested in the procedures followed to produce the document will find the commit + PR anyway, but I'm not against including it 18:06:42 thanks nightpool[m]. Between github and the w3c servers it has to go through svn :D I expect the link to the resolution will be in the svn commit message too, but I also find it helpful to be very transparent about it, because if github goes down the commit history might not be easily available to many people 18:07:41 cwebber2: looks like nightpool and I have converged the PR details, it's ready to go 18:07:50 cwebber2: let me know when it's merged and I'll contact ivan 18:15:32 rhiaro: cool, doing so now 18:16:35 \o/ 18:18:26 merged! 18:19:48 thanks cwebber2! 18:24:18 thank YOU for taking the lead on this rhiaro ! 18:24:39 and thanks also to nightpool[m] for all the careful review and representation of the activitypub-community-usage side 18:25:16 rhiaro: btw re: the "good call on this not being a list" thing, I phrased it badly 18:25:24 but I meant good call on not including "@container": "@list" 18:25:46 which might be the right call for a DID context 18:25:52 but not for the general AS2 context 18:31:03 cwebber2: hmm I think it's right for AS2 as well. All the other properties which are URIs and can have multiple values in AS2 are that way 18:31:10 and I don't see why we'd need ordering 18:31:17 rhiaro: yes that's what I'm saying 18:31:28 right, DID and AS2 match there 18:31:31 oh 18:31:34 I misread on the DID end then 18:31:40 I thought it said that it *was* an ordered list 18:31:43 on the DID end 18:31:51 the list stuff in DID is just because of how INFRA works, in combination with it being JSON syntax rather than being defined in RDF 18:32:07 huh what's INFRA... 18:32:21 it says it's an INFRA list, which is technically ordered but the order doesn't actually matter for our case and can be non-deterministic 18:32:34 yes, a bit confusing.. INFRA is an abstract data model definition syntax thing 18:32:41 https://infra.spec.whatwg.org/#lists 18:34:19 INFRA has "list" and "ordered set", both of which are actually ordered, but the "ordered set" can't contain duplicates. There's a note somewhere in INFRA about why the define everything as ordered but you can ignore it if you want 18:34:35 I think more language might go into DID to clarify the ignoring part, cos it's tripping a few people up 18:34:46 actually I should probably do that or something 19:07:24 > Almost all cases on the web platform require an ordered set, instead of an unordered one, since interoperability requires that any developer-exposed enumeration of the set’s contents be consistent between browsers. In those cases where order is not important, we still use ordered sets; implementations can optimize based on the fact that the order is not observable. 19:16:02 yeah, that 21:48:39 tenma has joined #social 21:49:08 includeals has joined #social 21:51:10 someonewithpc has joined #social