Meeting minutes
Introductions and Announcements
acoburn: US transitioning to daylight savings time
… this meeting is tied to US time
TallTed: reminder to subscribe to the W3C calendar
acoburn: this means that for the next three weeks, Europeans will be joining one hour earlier
<ericP> Zakim: take up next agendum
Action Items
ericP: first item is #11
<gb> Action 11 add categorization to the needs discussion labeled issues (on hzbarcea) due 2025-01-13
hadrian: this is the recurring item, we'll skip it
ericP: introduce owner and controller in glossary
hadrian: no time this week, planned to do in the next days
ericP: do you need assistance?
hadrian: help will come in the form of comment
Glossary
hadrian: this is PR #123, there is a comment that some definitions are too specific, but these come from NIST and other standards bodies
<gb> Issue 123 not found
hadrian: some comments from Ted related to dashes
TallTed: replaces hyphens with m-dashes, other comment is to sort by alpha-numeric
hadrian: will update the sort order, will need to figure out how to input m-dashes via markdown
<TallTed> fwiw, GitHub Markdown lacks a way to write m-dashes. They take `--` (two hyphens) and render `–` (an n-dash). Other markdown systems take `--` (two hyphens) and render `—` (an m-dash), while still others take `---` (three hyphens) and render `—` (an m-dash).
<TallTed> On macOS, you can type opt-hyphen to get an n-dash, and opt-shift-hyphen to get an m-dash.
TallTed: Shift-Option-hyphen on a mac works. Also copy-paste works
… the +1 on Sarven's comment is related to the generality
hadrian: will write back to Sarven to ask to be more specific about which terms are too specific
<ericP> agendum
hadrian: the comments and criticisms are all helpful, because they lead us to a better solution
ericP: is there anything we can do to help Hadrian?
what we can do to help Hadrian with UC&R
hadrian: some thoughts to begin to think about: identity and local-first
… self-soverign identity will be challenging with DNS
… local first implies the existence of a service that views the data locally, e.g. serve as a web page, perform query
… how much of this does the group want to take on? The challenge will relate to setting boundaries and limiting scope
… these two are the biggest challenges to sort out early
<Zakim> ericP, you wanted to propose that there may be constellations of features that we're unsure of what to specify
ericP: when someone writes a UC&R how can one not write solutions into that document, which can annoy people
… however, giving an editor latitude, such as using "for example" can be useful
… in specs there may be a constellation of approaches, e.g. "for DID, the following three..." or "for DNS, the following options ..."
… I propose we give the editor a lot of lattitude to write things down in order to get a draft out and to start a conversation
… the UC&R document is an opportunity to write a story that grounds the WG
… would that mandate help you, Hadrian, create a more coherent document?
<TallTed> s/Other markdown systems take `--` (two hyphens) and render `—` (an m-dash/
hadrian: that sounds good, but if my ideas are very different from the rest of the group, it would be helpful to get early feedback from others
ericP: the best approach is to just write things down and get feedback
hadrian: it would save us time to have these discussions earlier
… there are tradeoffs for local storage vs. network interactions. Some guidance from the group would be helpful
<Zakim> ryey, you wanted to comment on difference between local-first vs local-storage
ryey: want to distinguish between local-first and local-storage. To me, these are very different
hadrian: the big issue is portability
… if I move to a different provider, I want to have the same types of services
ryey: to me portability is very important, but I'd like more clarification. It seems less about local-first
ericP: are you discussion the difference in understanding or the difference in expressing this
<Zakim> ericP, you wanted to say that we'll work it out. the end of the editing process can trim stuff we don't want
<Zakim> bendm, you wanted to agree with ericP that this latitude will help uncover ambiguities or mark areas such as eg DID alignment
TallTed: when I think of local first, the data will be on my primary storage location
… i.e. local to me in a physical context
… Local first is to write to the primary location and then replicate out to other locations
… part of the game is to describe the functionality we want
… and then to describe what the software features are that meet these features
… e.g. "I need to read a thread of conversation"
<TallTed> ack
<Zakim> TallTed, you wanted to describe what I think of as local-first vs local-storage
hadrian: I agree with that, but I was thinking more of the use cases where you want to build a query service
… which likely will be hosted on the same machine, so the query service will see the data as local (rather than via HTTP)
… but if you port your data to another location, and someone else builds a query service, how can we ensure that feature is portable
<dmitriz> +1 agree with Ted, that we should specify the storage structure only minimally
TallTed: we should be minimally involved in the details of the implementations. The question is are the required features available
… the requirements are built on use cases. The features satisfies requirements
… we don't specify the "how". We specify the what
… the internals are mostly opaque and should stay that way
… we should minimize what we are delivering in terms of the specification
… they don't *have* to write into a SQL engine or Triple Store. It is sufficient that we define the API
bendm: wanted to agree with eric that we should uncover ambiguities
hadrian: the most difficult part is still portability. If I see a storage, what am I looking at?
<TallTed> portability is a user-story/use-case. the net result is that (some) functionality which was available at x is now available at y.
jeswr: my understanding of portability, it seems that when you talk of portability, you also talk about dev-ops and tracability
… I don't think we have time in this WG to standardize that level of portability (e.g. metadata formats for traceability)
hadrian: I agree that we should not define this, but we should indicate how these value-added features can be added to an implemenation
… for example, if provider A supports a feature and the data is moved to provider B, how would provider B understand what provider A saw in the data?
<Zakim> TallTed, you wanted to talk more about portability
TallTed: this is a question of how far into the weeds we go. They are important to consider, but aren't in the realm of specification
… they are in the realm of use cases
… one issue that many users have identified in the realm of social media includes exporting data
… google can export data, but it's basically a blob with minimal metadata
… IIRC, you don't get comments
… FB is similar, you can export data, but it is not structured or portable
<dmitriz> hey, for what it's worth, the SocialWeb CG has an in-progress account export format..
TallTed: that is part of a user story that we might imagine: take data from google plus and put it on facebook
… that is something that LWS could deliver
<dmitriz> https://
TallTed: e.g. when a user exports data, they should be able to get the data in a form with enough structure that it is usable
… what we want to try to do is to enable enough as is possible with loosely-bound specifications
<TallTed> note that I didn't get *deep* into what's exportable -- who read my post, who read joe's comment on my post, etc.
dmitriz: in the social media use case, this is relevant for the social web WG, which specifies a very light weight export format. There is a link describing what this looks like. The focus is on the manifest
<ericP> queue: ryey
dmitriz: a tarball of all the data and directories and a manifest that describes what is contained
<Zakim> ryey, you wanted to comment on "verifying"/"proving" the "imported" data
ryey: re import/export between storage providers, I'd like to add a point about verifying the data
… there must be ways to verify this, such as cryptographic techniques. Are there better ways?
<ryey> (maybe relevant) Trust Spanning Protocol https://
dmitriz: re verification, in social CG, we're approaching it in a layered approach. First layer, is just the data. Second layer, we want to sign the data. The agent is able to sign all the operations
<TallTed> requirements for data portability... (1) crypto-signing and similar verification that xyz was exported and xyz was imported; (2) that same "fields" and their "ranges"/"domains" are used; (3) that photo-abum app xyz and zyx use same "fields" and "ranges", and support same graphic formats; (4) ...
dmitriz: Verifiable Credentials are used to track provenance
<Zakim> ericP, you wanted to ask dmitriz if there were some guiding principles for how deep to code interopperatble structures vs. free text misc
ericP: all of these affect interoperability
… we want guarantees that we understand the structure
<ryey> Great to hear that dmitriz! Are there any pointers to that layered stuffs as a spec?
ericP: in the social CG, how far did the group go in terms of specifying the format of the export data
dmitriz: all the data is formatted as JSON-LD. Each impl introduces new fields, and for the programmers that write the import/export fields, they need to understand the new fields
… in linked data, we have links to human-readable documentation
<dmitriz> yeah, would be great to see ya'll at IIW!
hadrian: ryey mentioned verification, but I don't recall seeing a use case about this. Please add one, if there isn't one
… IIW is next month and I plan to attend, please reach out if you plan to attend
… this conversation was very helpful for me because it gives me much more direction
TallTed: making note that we've been talking about some different applications in this conversation
<dmitriz> (in case people are curious with how we're thinking about verification aspect of it, here's the 'Roadmap for Actor and Object Portability' doc https://
<dmitriz> (again, not official spec, just in progress)
TallTed: social media use case, but there are other applications. This requires that the same fields/schemas are used
… I also want to be able to migrate photo albums, e.g. I want to store my pictures and share them with different groups
… how we do that gets into the implementations that are derived from the use cases and requirements
… if we approach all at once, it's too big
… the storage has limited requirements
… photo application needs to be able to say: give me all the pictures with this tag, etc
… maybe there are extension points
<ericP> adJOURNED
<TallTed> IIW -- Internet Identity Workshop -- https://
<TallTed> s|s/Other markdown systems take `--` (two hyphens) and render `—` (an m-dash/||