W3C

- DRAFT -

Social Web Incubator CG

07 Nov 2020

Attendees

Present
cwebber, nightpool, dmitriz, rhiaro, manu, vpzom, sebastian
Regrets
Chair
cwebber
Scribe
manu

Contents


<sl007> we are on mumble

<rhiaro> scribenick: manu

<rhiaro> chair: cwebber2

<scribe> Meeting: Social Web Community Group

cwebber2: Here's the agenda...

<cwebber2> https://socialhub.activitypub.rocks/t/socialcg-meeting-on-november-7th-16-00-utc/1106

<kaetahbo> don't

<kaetahbo> do that

sebastian: Would like to thank CCG for giving the call a home.

cwebber2: We have a number of items -- let's start with alsoKnownAs

<xkr47> /kick Zakim

<xkr47> rhiaro, I have no authority to do so, but this nickspamming is disturbing

Officially make alsoKnownAs part of the AS2 vocabulary 3

<xkr47> rhiaro, it is fine :)

cwebber2: Let's start with alsoKnownAs
... 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.
... DID WG would like to make use of it
... So, we it would be great if we could, as CG, to ratify as an extension -- could do this in the meeting.

<rhiaro> definition in DID Core: https://w3c.github.io/did-core/#alsoknownas

<rhiaro> pull request to add it as an AS2 extension: https://github.com/w3c/activitystreams/pull/512

<cwebber2> 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

cwebber2: Yes, that makes sense.

<Loqi__> [rhiaro] #512 Extension: alsoKnownAs from DID Core

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.
... Just wanting to wait to see if there is any input?

<maymay> +1 for alsoKnownAs

<dmitriz> +1 for alsoKnownAs

<cwebber2> manu: is there concrete spectext?

<cwebber2> ack nightpool[m]

<Zakim> nightpool[m], you wanted to talk about the current definition

nightpool: Thanks Chris, I think we did some work in defining it in the wiki?
... I'm trying to look it up -- thought some of those early extensions in AS namespace, thought we took a swing at defining them.

<sl007> https://socialhub.activitypub.rocks/t/defining-alsoknownas/907

nightpool: I know I made it for just one of them...
... Let me look at my gist.

sebastian: I think Amy mentioned the specs in social hub location.

nightpool: I believe Amy just linked to Mastodon docs.

cwebber2: We did it for sensitive at least.

<Zakim> rhiaro, you wanted to answer manu's question

<cwebber2> I believe this is the discussed link https://www.w3.org/wiki/Activity_Streams_extensions

<rhiaro> https://w3c.github.io/did-core/#alsoknownas

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.

<cwebber2> looks like it covers as:Hashtag, as:sensitive, as:manuallyApprovesFollowers

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.
... Peopel from Activity Pub side or DID side change that before DID Core goes to CR.
... Might be worth talking about how to coordinate both groups.

<rhiaro> pr: https://github.com/w3c/activitystreams/pull/512

<Loqi__> [rhiaro] #512 Extension: alsoKnownAs from DID Core

cwebber2: link in IRC
... That has spec text definition, reading it out loud
... alsoKnownAs

The value of alsoKnownAs MUST be a list where each item in the list is a URI conforming to [RFC3986].

This relationship is a statement that the subject of this identifier is also identified by one or more other identifiers.

cwebber2: That feels like a clean definition to me
... nightpool, does that address your understanding?

nightpool: Yes, in actual AS namespace, just linking to DID Core.
... Yes, that definition makes sense, although, I guess it's a little weird.

<rhiaro> it's deliberately as generic as possible..

cwebber2: Could I ask for clarity on what's weird?

<rhiaro> and also has aspects that are specific to how the DID spec is defining terms (like INFRA)

nightpool: Not entirely clear on DID spec, seems specific to DIDs...

cwebber2: Let's get to the queue, Manu might comment on that.

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.
... We have rel=me and nightpool pointed out that this is more like rel=alternate than rel=me.
... The rel attributes can provide alternate protocols --

<Zakim> manu, you wanted to suggest we do this iteratively

cwebber2: two things to respond to -- subject identifier, is it did specific, then rel stuff...

<cwebber2> 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

<cwebber2> 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

<cwebber2> 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

<cwebber2> 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

<cwebber2> manu: about rel, I think that's fine, but I think that could be a separate conversation

<cwebber2> 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

<cwebber2> ack nightpool[m]

<Zakim> nightpool[m], you wanted to the rel= question

nightpool: Yes, wanted to confirm that I think sebastian is not in IRC -- said something that didn't get proxied.

<csarven> `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`

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.

<csarven> * Doesn't need to be `rel="alsoKnownAs"`

<csarven> hence, don't have to go through IANA

<Zakim> rhiaro, you wanted to talk about the DID specific bits

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.

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.
... 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.

<Zakim> cwebber, you wanted to see if we can get consensus

<csarven> AS spec and vocab are not tied. Can add terms to AS vocab ;)

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

extensions, both within and without AS vocabulary -- also about known patterns of deploying ActivityPub.

<csarven> And? this is about adding a term to AS2 vocab/context, no?

<csarven> spec doesn't need an update

<csarven> Just as we added ldp:inbox to LDP vocab... remember?

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.
... I have a suggestion of the path forward.
... Feels like we're going to have the followign things happen:
... 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.

<csarven> in the vocab

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.

<csarven> vocab describes itself

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.
... If we generally agree with that, we might be able to get consensus.

<Zakim> manu, you wanted to note Amy's right -- how do we want to proceed? and to defer to Amy :P

<cwebber2> manu: yes I agree with that, though I defer completely to rhiaro because she's done the real work

<csarven> have W3C conneg the AS2 vocab to HTML(+RDFa) .. or create one eg. see https://www.w3.org/ns/ldp in text/html

<cwebber2> 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

<csarven> what's the extension URL?

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?

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?
... Do you agree that it is not a blocker for this, but can be complimentary.

sl007: Yes, exactly -- wanted to know your thinking, but would then take lead and talk w/ Aaron Parecki on Micropub.

cwebber2: Let's make this a topic for next meeting? Sounds like you and nightpool have given it a lot of thought

rhiaro: What you put in IRC, the 1-2-3 points sounds right.
... 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?
... Once CG Report is published, can it be updated?
... Thoughts on the suggestion?
... Starting w/ generic part of definition in DID Spec, AS points to it until something more appropriate per the definition points to something better.

cwebber2: That soudns really good to me.

<rhiaro> +1 complementary

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.
... 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.
... does that sound acceptable?

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.

manu confirms that he believes what rhiaro said to be correct.

cwebber2: rhiaro, do you want to try to make a proposal?

rhiaro: gimme two seconds.

<Loqi__> hehe

sl007: Just wanted to see if pukkamustard is here? Intro on fediverse enhancement proposals?

<cwebber2> I haven't seen them on jitsi but I'm very interested in that

<cwebber2> the FEP

cwebber2: /me +1 to both proposals.

s/cwebber2: \/me/\/me/

<cwebber2> ack nightpool[m]

Amy makes two proposals.

nightpool: I thought we wanted a more general definition that was unrelated to DID Core spec?
... That doesn't seem like that's here in the proposals... but I guess DID Spec wants something normative.

cwebber2: You're concerned because of language -- subject of this identifier and list thing is problematic?
... This permits us to start iterating because of "as a starting point"
... 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.
... Amy does that match your thoughts?

rhiaro: Yes, exactly -- identifier and subject are meant to be general...
... The subject could be an Activity Pub profile URl -- supposed to be general/generic language... relationship is alsoKnownAs -- ANY identifiers, HTTP URLs, DIDs, etc.

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.

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.
... Does that make sense?

nightpool: Yes, that makes sense, and we don't want CG Report to be a blocker on DID WG.

cwebber2: Is that aligned, rhiaro?

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.
... 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.

cwebber2: It sounds like nightpool and rhiaro are in agreement, nightpool do you feel like that answered your questions?

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.

cwebber2: Within AS usage -- could specifically mean this -- ok... let's get to the vote.

<rhiaro> 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

cwebber2: Let's get votes in..

manu: +1

<rhiaro> +1

<cwebber2> +1

<dmitriz> +1

<paul> +1

<paul> not sure if I should have voting rights :9

<paul> I am

<sl0071> +1

RESOLUTION: 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

<rhiaro> 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

manu: +1

<cwebber2> +1

<rhiaro> +1

<paul> +1

<dmitriz> +1

<sl0071> +1

RESOLUTION: 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

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.
... Agreeign to merge that PR, that's a huge step there... we didn't get to all of our agenda items.
... Some of these other things might be easier now that we've had progress on alsoKnownAs --

dmitriz: When is the next meeting?

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?

<dmitriz> +1 to either next week or the next nearby

cwebber2: Next week or week of 21st?

<dmitriz> yeyyyy

cwebber2: Ok, let's do this next week then.
... I'll post on social hub.

<rhiaro> Thanks for chairing cwebber2!

<Loqi__> manu has 1 karma over the last year

<cwebber2> what only one karma

<cwebber2> manu++

<Loqi__> manu has 2 karma over the last year

<dmitriz> lol

cwebber2: Great, congrats everyone on being productive during this meeting, take care!

Summary of Action Items

Summary of Resolutions

  1. 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
  2. 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
[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version (CVS log)
$Date: 2020/11/07 17:02:05 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision of Date 
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 0.94)

FAILED: s/cwebber2: \/me/\/me/
Succeeded: 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//
Default Present: cwebber, nightpool, dmitriz, rhiaro, manu, vpzom, sebastian
Present: cwebber nightpool dmitriz rhiaro manu vpzom sebastian
Found ScribeNick: manu
Inferring Scribes: manu

WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)


[End of scribe.perl diagnostic output]