<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
<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!
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]