Meeting minutes
Introductions and Announcements
acoburn: today is going to be a lot about looking at the Requirements
Action Items
acoburn: I know Pierre-Antoine is working on Echidna integration on our Use Cases & Reqs doc
… I know there's some open PRs. if he does join later, we may come back to this one
… unless Hadrian or Eric B. knows where that stands
hadrian: I did review and approve the PR. There's an issue with HTML generation, so I haven't merged it yet
acoburn: I'll add an action to follow up with Pierre-Antoine to sort out Echidna
… I know there's an open PR 168, and a related issue about duplication of definitions...
… once all that gets settled, which I think is more of an editorial kind of decision
… but if you want to just move forward with that, please do
kaefer3000: what's the best way of following the Use Cases discussion today, on our screen?
acoburn: I'll share a link. each PR has a Preview on it, so that's what I'll be linking to
<acoburn> Requirements Section in PR 170
hadrian: we didn't know how many requirements will be on the list. so, those columns could have been many. we decided - if the table becomes too wide, we'll break it up into relevant sections
acoburn: just ignore the table right now, it's for a future step
… lets jump to the next item
Requirement list winnowing
acoburn: this gives us a first pass on reqs, not a final list by any means
… there are 44 requirements as of this PR. that's a lot
… there's also a lot in here that arguably should not be requirements
… this won't be formal voting, I just want a straw poll, to get a sense
<acoburn> Requirements triage
acoburn: so lets get a sense for high/medium/low priority for normative text
… and there will be some items we're just not doing
… I'm hoping to get a sense for clusters
kaefer3000: it would be great to know this discussion in advance, so we can be prepared
<TallTed> +1 advance notice of this polling would have been very helpful
acoburn: that's why this is just a very preliminary straw poll discussion
<TallTed> even just as "a very preliminary straw poll"
acoburn: I think we can go over these at a high level (there will be multiple passes)
… the alternative is, we postpone this for another week
<gibsonf1> +1 on high level pass
acoburn: ok, lets at least go over these and identify what each one is, to familiarize
kaefer3000: so, the first question on the column is "Plan to implement?". I just want to raise - we're here to specify a protocol, so there are some things that everybody must implement, but it shouldn't be part of the protocol
… so we should be clear that this is more of a 'should it be in the standard'
acoburn: right, great question. I would expect that a number of these would have plenty of implementers, but not be part of the spec.
… for example, time series data support. there might be lots of interest, but no plans to implement it
… are there things that would make implementing hard? etc.
dmitriz: the plan to implement is more about filtering items out
acoburn: ok, so, Personal Data Projection
… this is about 'can you take personal data of some sort, and convert it to other formats (consumable by non-LWS applications for example'
<Zakim> gibsonf, you wanted to ask definition of personal data - anything in a data pod owned by a person?
acoburn: so let's do, 3 (high likelihood to implement), 2 (medium likelihood), 1 (low likelihood), 0 (non-normative), -1 (won't do)
dmitriz: the question really seems to be "automated content negotiation on the _server side_"
acoburn: right
<Zakim> gibsonf, you wanted to say you would have to be more specific about which formats, etc
gibsonf1: if added to the spec, it would need to specify which formats, right
bendm: how is Personal Data Projection different form Service Integration? but lets just go over these and familiarize
acoburn: yes, lets do that, we can spend this meeting going over and expanding the terms
… the question is going to be - server side vs client side
… (this is regarding Personal Data Projection)
ryey: I created that use case (data proj.), it also applies to - converting between RDF data formats.
… rather than RDF data to non-RDF
TallTed: this feels like its' not so much asking the protocol to do the transformation, as it is asking the protocol to support the client requesting a different content type than the server might have on hand
… so, this is more content negotiation.
jeswr: it seems we're hitting an issue that these requirements are too ill-defined to have an in-depth discussion
… can I suggest that for the rest of the meeting, we time box each of these to 2-3 mins, and try and assign someone based on the discussion, to write out the requirement more clearly
acoburn: that would be great.
… ryey, would you be able to wordsmith and expand that requirement?
ryey: sure
<kaefer3000> suggestion as per Ted's remark: add "the possibility to request" between support and projection
acoburn: lets go to the next one. Profile Interaction UI
… standardizing a method for clients to fetch and display a profile
… specifically for interacting with contacts
… are there questions about this one?
<bendm> no questions about that
acoburn: both of these items came from Sir Tim. I suspect they have to do with a Data Browser like UI
gibsonf1: can you give some examples of these, how would the UI trigger, what would the UI be for? I don't quite understand it
TallTed: to me, this feels like two different things. 1) fetch and display profile, very different from 2) follow message or share (that seems more like ActivityPub domain)
… so, number 43 be two separate things
<eBremer> i can do it
acoburn: any volunteers to clarify the text or refactor the wording?
acoburn: next one, Bring Your Own Data apps
… enabling third party applications to interact with user-managed storage, to discover capabilities.
… my first question is - is this actually a requirement? seems more like a user story
<jeswr> agree that it is more a story
kaefer3000: what kind of capabilities are foreseen here? unclear.
acoburn: this is an extremely broad requirement, it's more of a 'this is the whole point of the spec' kind of thing
<Zakim> kaefer, you wanted to ask what a Storage capability is
<Zakim> gibsonf, you wanted to comment on app generated data definition
gibsonf1: app generated content versus what
… what's non-app-generated content?
acoburn: I'm kind of in agreement with Dmitri - this is less a requirement and more of a high level description of this whole project
<Zakim> bendm, you wanted to combine/replace it with 20
kaefer3000: the key here - the app can manage its own data, versus that of other apps. maybe that clarifies?
bendm: requirements 7 and 20 already cover this, I don't see what item 42 adds.
acoburn: would you be able to take this one and maybe combine it with the others?
bendm: sure.. I'll just remove it, and make sure everything is covered by 7 and 20
TallTed: this feels premature. a 'bring your own data' app is one to which you feed data which came from someplace else. it's not about the app managing its own data, it's about the app interacting with _my_ data I already had
… so for example, I'm changing my photo album app from one to another, keeping all the photos, tags, metadata, etc.
… just changing the tool I'm interacting with photos, etc.
<gibsonf1> That sounds like semantic interoperability
acoburn: let's go to Network Flexibility. can the protocol work in environments with dynamic IPs, NATs, etc
… my initial reaction is - why do we want to specify routing in the protocol, that seems way too low-level
acoburn: next, Self-Describing Website Publication.
… can you do website content hosting directly from storage
<gibsonf1> +1 on generating website (already supported TrinPod)
TallTed: yeah, I don't think this is about Projection. I'm not sure that any part of this really belongs in the LWS protocol.
… this is more of an application of a number of tech that already exists, like HTTP, DNS, content type headers, etc
<Zakim> bendm, you wanted to ask whether that's actually requiring transformations
bendm: I was going to say the same, not about transformation, just about serving existing content from off-server
<Zakim> gibsonf, you wanted to comment on website
gibsonf1: on this one, we support it, and it does require server work, to say that a website's files (html etc) be displayed as a website
acoburn: lets go to Time Series Data support
kaefer3000: issue 31 is quite extensive, maybe we need a summary/clarification?
acoburn: I agree
<gibsonf1> +1
acoburn: I think issue 31 was an automated summary of what existed in those issues. Fred, can you go back and make sure the requirement is an accurate distillation of the issue? thanks
acoburn: ok, Time Series Data Support. this involves storing, querying and aggregating time-based resources for multi-dimensional analysis
TallTed: again, I'm not sure this belongs in protocol
… some of this is - this is the first time we're looking at this
acoburn: that's fine, my gut reaction too is that it's not appropriate for the protocol
bendm: yes, I was wondering, protocol capability wise, how the original need is different from creating projections on top of existing data
ryey: to me, the time series thing implies a performance requirement
kaefer3000: the examples in the use case is just storing data about readings into a pod. no mention of aggregation
… but the issue is fairly generic, not sure we need to keep it
acoburn: I'll reach out to Jacopo, ask him to clarify
… and next week we can decide
… ok, we have time for probably one or two more
acoburn: ok, Collaborative Editing -- this is basically CRDT merges, concurrency support, locking
… anyone want to elaborate?
acoburn: does anyone want to clarify this one?
dmitriz: I might, depending on what the other stories on replication and sync are
<kaefer3000> it was said that collaborative editing is just a special case of replicate and sync
jeswr: we should ask NextGraph for clarification on this one
… on what client and server capabilities are
dmitriz: agree
TallTed: this feels like this overlaps with bring your own data apps?
acoburn: ok, tiem for one more
… Delivery Receipts.
… this one is - does the protocol have a mechanism for sending verifiable receipts or acks when resources are created, modified, requested
… this came from the Auditable Proof/Receipt of Authorization issue
… kaefer3000: yes, sounds a lot like auditing, so, this needs logging functionality
… the thing in the other document is a bit different (delivery receipts)
acoburn: yes, this sounds like item 9, Auditable Trail. those should be combined
<TallTed> should it be downloadable once? or as many times as the authorized authenticated entity GETs it? or....? (and does this belong in protocol, or in data management?)
gibsonf1: this sounds more generic - read/write event audit, rather than purchases specifically
acoburn: ok, we're at time
<TallTed> some software sales permit license to be downloaded once (though it can then be replicated); others allow re-downloads
acoburn: let's stop for today, we'll continue over the next week or two
<kaefer3000> I asked whether should auditable trail, i.e. logging changes in access rights, be part of the prodotol?
acoburn: please review these and familiarize
<bendm> I'm happy to have a look at 37 to merge with 9
kaefer3000: we've had a few instances of - the summary doesn't match the issues. can we do a quality pass over this?
jeswr: I was going to suggest - for the items we haven't covered yet, people can go through them and identify ones they can elaborate requirements for async
… do we have a mechanism for people to self-assign?
… and also do the quality assurance etc
<bendm> can we meanwhile get suggestion/review rights on https://