#social 2018-07-18
2018-07-18 UTC
# 
dansup aaronpk: I saw your issue on the 99designs http-signatures library. I forked it to add support :)
# dansup tesla uses the ruby version, should check if they added support heh
# dansup aaronpk: Yeah, should have it done tomorrow, I'm working on other stuff. Already fixed the timing attack issue :) https://github.com/pixelfed/http-signatures-php/commit/a3b6985c632b7add360a24a507eae4187f2b51a4#diff-fd9277dc194dcb8f745dc53e058a26b1
xmpp-social, vasilakisfil, JasonRobinson[m], href, dlongley, cwebber2 and timbl joined the channel; jaywink[m] left the channel
# nightpool[m] morning all
cwebber2 joined the channel
ajordan joined the channel
# 
trackbot Please see <http://www.w3.org/2005/06/tracker/irc> for help.
# nightpool[m] rip trackbot :(
# nightpool[m] present+
# JasonRobinson[m] present+
# JasonRobinson[m] (though chatroom only)
# puckipedia present+
# nightpool[m] I would probably be video-muted either way, so it doesn't make a ton of difference to me
eprodrom joined the channel
# eprodrom +present
# eprodrom Not on the call yet though
# eprodrom present+
# eprodrom I prefer the prefix syntax so that my presence is incremented before it is evaluated
# nightpool[m] makes the sign of the cross against perl scripts
# puckipedia cwebber2: i feel like there's been a ton of activitypub stuff happening and i haven't been able to keep on top of anything that's been happening
# puckipedia cwebber2: it may be a good idea to start reviewing issues during cg stats
# puckipedia cwebber2: if we have space at the end of this meeting let's do it, else let's plan on it next meeting
# puckipedia cwebber2: first topic is eprodrom's. the AS2 editor's draft
# puckipedia cwebber2: the first two items are related, the draft and the extensino mechanism. is that right?
# puckipedia eprodrom: they are both related, as in related to AS2.
# puckipedia cwebber2: ok, so we'll handle them separately
# puckipedia eprodrom: basically, what we have with the final recommendation is a link to an errata document, on github
cwebber2 joined the channel
# puckipedia eprodrom: it's a md document, as we've been closing issues on AS2 we've been adding lines to that errata document
# puckipedia ... "this is what has changed, this would be a good replacement for it"
# puckipedia eprodrom: we had an idea, of adding an editor's draft (post-recommendation) and what we would do with it
# puckipedia eprodrom: i was reluctant to keep both an errata and editor's draft up to date,
cwebber2 joined the channel
# puckipedia eprodrom: we have this document, we have this place we keep editor's draft, not sure where, also on github?. and whatever we update in the errata we also update in the draft
# puckipedia eprodrom: they are post-release drafts that have the errata fixed
# puckipedia eprodrom: I would start to get reluctant to use [..] as a basis to do an AS2.1 or AS3, that feels like a place for us to start a new document
# puckipedia eprodrom: if we're going to keep an editor's draft up to date it feels like keeping them up to date on both places would make sense
# puckipedia sandro: so the errata document serves as two purposes, flaggin issues that haven't been addressed and that have
# puckipedia sandro: we'd point the errata document to github issues for things that haven't been addressed, and the ED for things that have been addressed, does that sound right?
# puckipedia eprodrom: no. that wasn't what I was suggesting. the errata has lists of errors, like example 150 [from document], that's where we are. we'd keep this. I'm suggesting we also have a version of the actual recommendataion that has that change
# puckipedia sandro: i thought you said you didn't want to maintain both
# puckipedia eprodrom: that was my initial feeling, strong momentum towards ED, this'd be a good moment. I'd be happy maintaining only an ED
# puckipedia eprodrom: ... two meetings ago, chris and I got in a discussion, i feel like we have a commitemnt to keep the errata document up
# puckipedia .. having an unbounded ED sounds like a bad plan also telling people to "look for AS is way over here on github instead of this published document" seems like a bad plan
# puckipedia sandro: the only change you're proposing is a draft that takes the REC and implements the errata fixes, and link that from the top of the errata document
# puckipedia eprodrom: correct. maybe also link it from the github repo too
# puckipedia sandro: that sounds great to me. there's a newer simpler process for getting errata fixed in recs, so at some point there's nothing that's worthwhile we don't need a new Working Group. it's not worth it for a while yet but that makes it simpler
# puckipedia cwebber2: I want to get ajordan in for a second, can you clarify what that process is?
# puckipedia sandro: i don't remember
# puckipedia ajordan: i had a small question for eprodrom, you wouldn't be ok with an AS2.1 document, you mean that until, assuming there's a new WG, [..] we haven't decided to make a 2.1 document?
# puckipedia eprodrom: this wouldn't be for normative changes, it's really for editorial changes
# puckipedia cwebber2: i'm next, but maybe before i raise my question, it'd be good to get a mood of the room on eprodrom's proposal, your proposal is "keep fixes in the ED, comaintained with the errata document", right?
# puckipedia eprodrom: it wouldn't be fixing the protocol, it'd be fixing the serialization [?]
pea joined the channel
# puckipedia cwebber2: I was thrown off and corrected in that CGs can't do formal proposals [.. totally missed the rest]
# eprodrom PROPOSED: The CG will maintain an editors' draft of the AS2 document, applying the editorial changes listed in the ERRATA document
# pea yes
# puckipedia cwebber2: pea, you're a new member, you're talking about representing pleroma, who i was talking to on the fediverse?
# eprodrom \o/
# puckipedia cwebber2: btw if you haven't done so, you have to go through the join form on the socialcg page
# pea I understand, just listening in for now.
# 
Loqi sandro: ajordan left you a message on 2018-05-25 at 12:17am UTC: I know it was from a couple of days ago but FWIW if you forget the !tell syntax again, Loqi is documented: https://indieweb.org/loqi
# eprodrom +1
# nightpool[m] +1
# puckipedia +1
# JasonRobinson[m] +1
# pea For clarification, not representing pleroma but I do contribute occasionally
# pea +1
# puckipedia cwebber2: i think we can mark that as resolved
# eprodrom RESOLVED: The CG will maintain an editors' draft of the AS2 document, applying the editorial changes listed in the ERRATA document
# eprodrom Hooray
jankusanagi_ joined the channel
# puckipedia cwebber2: it's bit of a jumping into another topic, since we're taslking about AS2 and ED. it might be interesting to talk about AP and ED as well
# puckipedia cwebber2: I kinda have a proposal for the what the current direction of AP is
# puckipedia cwebber2: are people ok with jumping into that topic? it's maybe a bigger one but i can keep it to 5 minutes
# puckipedia eprodrom: i'm going to do an initial ED of the AS2 documents with the errata that we have closed off so far
# puckipedia ajordan: are you going to do that in the same place?
# puckipedia eprodrom: that was my plan
# eprodrom topic change idea
# puckipedia cwebber2: my proposal for now, we have a few issues coming up on the issue tracker, my feeling is that what we shuold do is the same proposal that eprodrom laid out, but with AP it didn't specify the behavior of all types, and some AP implementations are now starting to formalize on what the behavior of these is
# nightpool[m] q+ to talk about draft/extensions split
# puckipedia cwebber2: it may make sense to, as one additional thing, we could take proposals of additions as append-only extensions, mostly around type behavior
# puckipedia nightpool: it seems like the thing we're doing in AS is split extensions and drafts to the specification, do we think there's place for an AP extensions thing that doesn't affect the text?
# eprodrom That's our next topic!
# puckipedia cwebber2: i think that makes a lot of sense, it may make more sense to captures things when it [..] the core types of AS
# eprodrom q+
# puckipedia ajordan: this feels like it should be a separate document, mostly because i see it as being easy to get the AP ED confused with the published version
# puckipedia ajordan: if you're looking for new stuff, the new types, that's not obvious if you're looking at [..] document
# puckipedia eprodrom: i think there's an interesting boundary between editorial and normative, andour next boundary being normative and non-backwards compatible normative, a verb that isn't specified in AP, "people are using it as this", wouldn't be a problem to define [..]
# nightpool[m] This didn't get scribed, but I think there's an argument to be made that extending instead of modifying activitypub may make less sense then extending instead of modifying acivitystreams because one is a full behavior spec and the other is a vocabulary.
# puckipedia cwebber2: next item is AS2 extensions
# puckipedia nightpool[m] yeah, sorry, missed that
# nightpool[m] np!
# puckipedia eprodrom: so how do we want to deal with quote unquote extensions
# puckipedia eprodrom: we've been talking about extensions in different ways [..]
# puckipedia eprodrom: we talked about this a couple meetings ago, i threw it out there
# puckipedia eprodrom: i hope we can have a thumbs up thumbs down
# puckipedia eprodrom: it lists out four kinds of extensions
# puckipedia eprodrom: first is existing vocabs used in AS2 documents, like the security one for http signatures, but also schema.org, vcard, ldp
# puckipedia eprodrom: these are existing vocabs that people are including
# puckipedia eprodrom: all we need to do for these is list them out on the extensions page, says "these are extensions you may see used"
# puckipedia eprodrom: it is neither comprehensive nor prescriptive, just a list of links that's helpful to someone who's implementing
# puckipedia eprodrom: the other thing is that we may add them to the AS2 context document, especially if there's no conflict
# puckipedia eprodrom: we have a couple issues to add security and vcard, i think that in cases where they're widely used, no big conflict, let's go ahead and do it
# puckipedia eprodrom: second kind is single-implementation. these would be extensions that are very specific for an implementation
# nightpool[m] joinmastodon.org/ns#
# puckipedia eprodrom: for pump.io for AS1, we have some pumpio specific features. there's a similar used for mastodon, we'd [put it in the document]
# puckipedia eprodrom: another type is multi-implementation extensions that are still in development, like dating websites
# puckipedia eprodrom: if we start exploring this, we could set up a dating namespace, still in development, if you want to start putting dating info in your AS2 doc, this is the namespace we're working in
# puckipedia eprodrom: start with a github issue, give it a namespace, ..
# puckipedia eprodrom: last is well-established extensions, [.cut out.] we hsould not just put the namespace in the AS2 document, but also the terms
# puckipedia eprodrom: bar conflicts, we should just include it in AS2
# puckipedia eprodrom: last two, big difference is that ones that are still in development we'd tend to use with prefix, ones that are no longer in development we would drop the prefix
RRSAgent joined the channel
# 
RRSAgent logging to https://www.w3.org/2018/07/18-social-irc
# puckipedia eprodrom: one goal between this third and fourth group is that the expanded version of the name stays the same
# puckipedia eprodrom: so it should be the same uri
# nightpool[m] q+ to talk about "misc" extensions
# puckipedia eprodrom: otherwise noone ever moves
# puckipedia eprodrom: the process is going to be mostly cataloging extensions we're going to see, adding namespaces and possibly terms to the AS2 context document
Zakim joined the channel
# puckipedia eprodrom: these'd be guidelines
# puckipedia cwebber2: i think this document is awesome, but there's a queue, so we should jump to the queue
# eprodrom q?
# nightpool[m] again, https://github.com/w3c/activitystreams/wiki/Extension-process is the document the summarizes this
# puckipedia sandro: so i have a couple thoughts, the key point is: what happens when i'm developing and i want an extension, [...]
# puckipedia eprodrom: quick note, are you in a type 2 one, because it's specific to your impl?
# puckipedia sandro: i haven't convinced anyone else
# puckipedia eprodrom: so type 2 is, for pumpio we put the internal database id in there, it's like debugging info
# puckipedia sandro: so i intend it to be type 3, i'm the only implementation but i want others to use it
# puckipedia sandro: so first, where do i [..] that, does that fall in type 3?
# puckipedia eprodrom: that would be type 3, even if it's only one impleemtnation or one person who thinks it's a good idea
# puckipedia sandro: now, so say i have this thing in my implementation for public use, and it starts to catch on. i've got it used by a few thousand users, there's [..], there's now a few million documents with this namespace
# puckipedia sandro: this qualifies as well-established, now all those documents have to be changed?
# puckipedia eprodrom: welllllll, that's a good question
# puckipedia eprodrom: my hope is that we don't have to change these documents
tantek joined the channel
# puckipedia ... if we do the context correctly we can do it in a way where using a prefixed external namespace or without prefix would result in what is the same URI for a property
# puckipedia nightpool: this is similar with how activitypub is compatible with the LDP inbox, using the same alias/expanded uri for their inbox properties
# puckipedia cwebber2: we don't want to have old documents suddenly change context, that would break signatures and things like that
# puckipedia eprodrom: we want less frequently changing context documents, e.g. dating, i've added some properties that are related to dating. like which gender you're seeking, geographical restrictions
# puckipedia eprodrom: and then there's a namespace which is, i called it a "subnamespace", i don't know if that's kosher
# puckipedia eprodrom: it's a namespace that's in w3.org, looks like part of activitystreams
# puckipedia eprodrom: this is [cut out]
# nightpool[m] i don't know if zakim knows there's a meeting going on
# puckipedia eprodrom: if people think it's worth adding to as2, it'd be added into the AS2 context, we'd do aliases for every property
# puckipedia sandro: so it would always remain in the subnamespace
# puckipedia eprodrom: yeah
# puckipedia sandro: that's cool, but my second question would be subnamespaces, i'll go through the queue again
# puckipedia nightpool: the concern i had last time, before i get to my concern, there's an issue objecting to this that i don't believe anyone here is representing, it might be useful to read that issue
# 
cwebber2 is it this issue? https://github.com/w3c/activitystreams/issues/479
# puckipedia nightpool: my concern is, there's some extensions that don't seem to fall into any semantic subnamespace, as:sensitive is what I'm thinking of
pea_ joined the channel
# puckipedia nightpool: an NSFW property doesn't seem to fall into any meaningful subnamespace, i wonder how stuff like "miscellaneous" falls in any [..]
# puckipedia nightpool: there's also things like dating that would never move out of their subnamespace
# puckipedia network blip
# puckipedia sandro: I think we can get rid of subnamespace, they might be more trouble than they're worth
# puckipedia eprodrom: i will start off giving my answer to the previous question, NSFW, there's no big problem with having a namespace that is NSFW and it's got one property, that's NSFW, as it moves forward we bring it into the main document
# nightpool[m] tantek, ultimately, because images don't have tags
# puckipedia eprodrom: with the dating example it suggests there's a whole schema of stuff in the dating namespace
# puckipedia [.bleh.]
# nightpool[m] I kind of regret using "nsfw", the property in question is as:sensitive.
# puckipedia eprodrom: for sandro, i would like to hear, there's an objection to using subnamespaces, i don't care that much, so if we use some other namespace that's fine too, this process will work even if the namespace is absorbed and becomes part of the AS2 context document anyways
# puckipedia sandro: that would be my default position, i see not much win to the complication of that
# puckipedia sandro: we need some kind of maturity standard, [..]
# nightpool[m] tantek: the author believes it would be sensitive to the intended audience
# nightpool[m] (but yeah sorry cwebber)
# puckipedia eprodrom: it's requiring that stuff that's in progress maintains forward compatibility, so we can't rename or remove properties that are wip [..?..]
# puckipedia eprodrom: it seems like a bad way to go forward with it
# puckipedia sandro: we can bend that rule, if the maturity standard is [low/immature] we can drop/delete it
# puckipedia eprodrom: there's naother part, our time and attention
# puckipedia eprodrom: just because someone says "we should have a property that does this" and they don't care about it enough to put the effort into maintaining it, that we have some kind of maintenance responsibility
# puckipedia eprodrom: having zero barrier to entry means it's a live dumping ground for anything [..]
# puckipedia sandro: if someone wants to revive it, that brings the energy for [something] new
# puckipedia eprodrom: someone comes up with a property, makes a gh issue, we patch the context document, we push it to w3c, we do the versioning there, and then whoever is doing LD signatures has to know there's a new version and deal with it
# puckipedia eprodrom: it's a lot of effort
# puckipedia sandro: I don't think people using LD signatures have to change to new versions, the other things are, one would hope, things one would make lightweight
# puckipedia ajordan: so the suggestion of removing things of the context, is that still on the table?
# puckipedia sandro: let's say no
# puckipedia cwebber2: eprodrom is suggesting we put stuff in semi-unofficial namespaces to work on until they matuer and get community concensus, then have a way of pulling them in and making them official
# puckipedia cwebber2: it seems like sandro's suggestion is "why do we have subnamespaces at all, we couldj ust have them be extensions in the same namespace and still do this append-only thing" and if i understand eprodrom's objection to that objection
# puckipedia cwebber2: that's going to create a lot of work to [..]
# puckipedia eprodrom: lastly is that if we were just putting whatever experimental stuff people want to in AS2 we'd sacrifice our requirement to not change/delete properties, or that the experimental process not delete/change properties
# puckipedia tantek: I tried to catch up on the discussion, this feels like we're not solving an issue that is specific to social, as2, or mastodon
# puckipedia tantek: it's a problem worth solving and we're running into real-world iteration evolution issues
# nightpool[m] q+ to talk about unique json as2 space
# puckipedia tantek: the JSON-LD working group either solved or should solve this issue, if there's another group that's doing this they'd have the same issue with evolving [..]
# puckipedia tantek: it feels like we're making up a bunch of stuff that should already be defined, or are we missing something that makes this situation happen?
# puckipedia tantek you're echoing
# puckipedia nightpool: so, AS2 is a little bit unique, we haven't addressed this much, as a spec it does try to cater for both JSON-LD and people reading it as "pure json"
# puckipedia nightpool: we havenm't talked about this, but it does put us in a unique position
# puckipedia tantek: first, you're right that we're in a more challenging situation, i don't think we could assume json-ld context processing, even in that situation it isn't well defined
# puckipedia cwebber2: so we're in territory that is slightly up for debate, [..] what people have been doing is, a. discussions about vocab increasing, and discussions about increasing [contexts?]
# puckipedia cwebber2: it is easy to confuse them. the general best practice is it's ok to do append-only updates to vocab, generally
# puckipedia cwebber2: there's no advicement when to append things
# puckipedia cwebber2: there hasn't been a lot of dicussion abuot the maintenance burden, which is higher for AS than other specs, as there's so many imlpementations experimenting with things right now
# puckipedia cwebber2: comparable is schema.org, which is append-only at a fairly rapid rate
# puckipedia cwebber2: they add a lot of stuff, it's huge, and they do have an extension process, they mark things as experimental and eventually they get pulled into the main context
# puckipedia cwebber2: it's generally understood that append-ionly is a good structure, if you add it there's an expectation you don't remove it
# puckipedia cwebber2: we've talked before how this can screw things up with linked signatures, there's a few issues in json-ld[?] land dealing with content-addressable storage
# puckipedia cwebber2: for best practices, append-only, the rest is up in the air
# nightpool[m] s/content-addressable storage/content-addressable contexts/
# eprodrom q+
# puckipedia cwebber2: i know people in the WG and I propose that i show up as a [guest], if people find that interesting
# nightpool[m] What is schema.org's extension process?
# nightpool[m] https://schema.org/docs/extension.html seems to be the correct document
# puckipedia sandro: i agree with tantek's intuition, my reading is that we're on the cutting edge of cutting edge development, that's not a thing that happens very much, most people do json-ld in narrow environments. in principle, json-ld would handle this, i'd be happy to attend a call for them, maybe face-to-face at [tpac?]
# puckipedia sandro: i'm ok staying past the top of the hour, i might have to disappear
# puckipedia cwebber2: let's not extend past this topic
# puckipedia cwebber2: how about extending 15 minutes
# eprodrom +1
# eprodrom tantek: thanks so much!
# nightpool[m] +1 for no further agenda items
# puckipedia sandro: :3
# nightpool[m] puckipedia++
# puckipedia eprodrom: one thing i like about the extension mechanism, is that the barrier to entry is implementation
# puckipedia eprodrom: if you've implemented a vocab, and hopefully you have interoperability, preferably 2+ impls, then great, that's a good time to bring it into the main context
# puckipedia eprodrom: that does not feel like structural barrier, may be a little meritocratic, but it's, money talks, suckers walk. if it's worth doing, implement it, show it, let's go
# puckipedia eprodrom: so it's not just someone doodling "this is what I think the properties would be" and then we have this big blob of someone's thought processes
# puckipedia eprodrom: I like implementation and seeing stuff implemented
# puckipedia sandro: so one bit of confusion, you seem to have two barriers, a low barrier of entry to the namespace, and a high barrier to the context
# puckipedia sandro: right off, i find the idea of getting those out of sync to be extremely error prone, i'd really we rather not do that
# puckipedia sandro: is that right, seperating those two?
# puckipedia eprodrom: i think what i'm saying is we'd have some mechanism of doing a new namespace, i think the idea of subnamespaces is so we aren't ghettoizing new namespaces(?), there's some real benefit to doing namespace that are hosted on other places, they can get changed much faster
# nightpool[m] "namespaces are a honking great idea let's do more of those"
# puckipedia eprodrom: so there's some value in that. for me, having a way to have a "subnamespace" is to bridge those two possibilities, having something that looks and says w3, but also could be rapidly iterated
# puckipedia eprodrom: if that's not something we could do, i would care less
# puckipedia cwebber2: so I wanted to represent what bengo objected
# puckipedia cwebber2: my read is that bengo thinks the w3.org is not a great place to move experimental extensions, they raised some things in "it could result in a name grab thing", the w3c doesn't have a good process
# puckipedia cwebber2: they ended up registering activitystreams2.com and activitypub.com, smart move, and they offered those to be extension sources
# puckipedia cwebber2: i don't see it as less of a name grab thing, just in a different place
# puckipedia I think it's user-namespaced as well
# puckipedia cwebber2: one concern we need to address, whatever process we use is one that the AS editors will actually follow
# puckipedia cwebber2: that is currentlyh eprodrom, as we don't have much participation from [james ??] anymore
# nightpool[m] s/[james ???]/james snell/
# puckipedia sandro: so one other bit of background, i currently have the job of trying to solve this in a broad way across w3c, and my proposal, i think, is going to be user namespace
# puckipedia s
# eprodrom tag:evan@fuzzy.ai,2018:dating:
# puckipedia sandro: so ns/[your username]/[whatever you want], so anyone can put anything they want in a w3 namespace, it's in a bit of a ghetto
# puckipedia sandro: the problem with that is that then, when you become mature, what happens
# puckipedia sandro: the answer may be "it stays in the user namsepace" and ther's an alias, maybe the alias happens in the consuming softare
# puckipedia sandro: both of those suck, but they may suck less than the alternative
# puckipedia eprodrom: i'd be more thumbs up for the first one, practically invisible in the way we're using json-ld
# puckipedia eprodrom: if that's the case, then it's almost invisible to implementors, everyone sees there's no change, the only change is they have one less line in their context
# puckipedia sandro: an interim we could do, is, for now, this policy, put type 3 into type 2, either you're in your own namespace, or you're well-established, for the latter we don't change the uri
# puckipedia sandro: we just add an alias
# puckipedia sandor: ... so the uris end up all over the place. however, you haveto ensure your hosting is stable and in perpetuity
# eprodrom q+
# puckipedia ajordan: am i understanding that we will wait for sandro to do something by october, i'm fine with that, but i want to verify
# puckipedia sandro: my closing sentence would be that we could adopt a policy that makes sense even now
# puckipedia sandro: i can't commit to any timeline, needs approval, etc
# puckipedia ajordan: so non-commitally, is that the general idea?
# puckipedia sandro: we could list some stable hosting places
# puckipedia eprodrom: in this namespace issue, there's an implicit idea we'd also, as CG, be doing some coordination
# puckipedia eprodrom: incubation of these extensions, right?
# puckipedia eprodrom: so, "hey, if you want to do something for dating in AS2, come tothe CG, say you'll do it, we'll have some space for you", and then it will "graduate" to be part of AS2 proper
# puckipedia eprodrom: versus, like, go off and work on this on your own, and hopefully other people will find you
# puckipedia eprodrom: and when this is ready we'll collect it
# puckipedia totally missed the last few sentences
# puckipedia cwebber2: if we have a github/gitlab group, set up separate repos for people who are declaring an extensino and people who seem to be maintining it to be administrators
pea joined the channel
# puckipedia cwebber2: that wuold be the least work for committing [..] and if someone ends up starting the dating repo, and then they could set up those as collaborator,s not sure if that's the right idea, throwing it out there
# puckipedia cwebber2: so, it seems we made quite a bit of progress
# puckipedia cwebber2: next time we try to work on issues during the call, that's a swell idea
# puckipedia cwebber2: if you have ideas, tell me, i'll add them to the wiki page
# puckipedia sandro: is anyone giong to be at the decentralized web summit?
# puckipedia wow SF, that's pretty central
# puckipedia cwebber2: thanks everyone for coming
# puckipedia cwebber2: I'll drop it in a thing in a bit
# puckipedia oh right
# eprodrom ajordan: np
# eprodrom So basically we're publishing AS2 and we have OAuth 2.0
# eprodrom That's all in master
# eprodrom What I've been working on in the ap branch is accepting AS2 posted to the inbox and outbox, converting it to AS1, then acting on it
# eprodrom That's taking longer than I thought
# eprodrom Also it is super boring
# eprodrom np
# eprodrom I think I created a bunch of issues, one for each vocabulary item
# eprodrom Otherwise I just created them in my todo.txt
# eprodrom I'll get them into the issue tracker and you can self-assign any that sounds non-odious
# eprodrom Umm, I think so
# eprodrom I think we already did the content negotiation bit, right?
# eprodrom Oh, the HTTP Signature support
# eprodrom Like, we'll need to check signatures and to sign things for distribution
# eprodrom There's an NPM module
# eprodrom AFAICT no
# eprodrom Oh, um
# eprodrom I think there is an auth-related change
# eprodrom Let me double check
# eprodrom I think we talked about it before, but the idea was that if you didn't provide an OAuth key you could get a document as if you were not logged in
# eprodrom Previously we've required OAuth key for EVERYTHING
# eprodrom So 2-legged Oauth 1.0 needed to look at a doc
# eprodrom Let me check
# 
tantek if you are, you're also invited to an informal dweb hackers day / Indiewebcamp SF on 7/31 @MozSF: https://indieweb.org/2018/SF
# nightpool[m] tantek: Sandro asked that question at the end of the meeting as well, so I assume at least he is
# eprodrom ajordan: so it looks like that change _didn't_ make it for this release
# eprodrom So, work we still have to do
# eprodrom I think there's already an issue for it
# eprodrom It was a dumb requirement from a different time
# eprodrom That came out of a specific frustration I had with identi.ca
JanKusanagi joined the channel
# 
ajordan https://github.com/pump-io/pump.io/issues/1566 is this what you were thinking of?
# eprodrom I thought there was another one
# eprodrom https://github.com/pump-io/pump.io/issues/760 ?
# eprodrom https://github.com/pump-io/pump.io/issues/859 !!!!!
# eprodrom Better
# eprodrom How does this project have soooooooooo many issues
# eprodrom Yeah but there are a lot by users too
# eprodrom I figure it means that people care, so that's a good thing
timbl joined the channel
# 
sandro tantek, next week, https://credweb.org/agenda/20180726.html
Zakim left the channel
fr33domlover, fr33domlover1, fr33domlover2, timbl, fr33domlover3, fr33domlover4 and tantek joined the channel
# tantek eprodrom++ for https://twitter.com/evanpro/status/1018205523470979073
fr33domlover1, fr33domlover2 and fr33domlover3 joined the channel