Video summary
The session focused on the technical architecture and core design principles of the Personal Data Portability Protocol (PDPP), specifically moving beyond high-level concepts to examine how data is modeled and communicated between sources and clients. A central theme was the distinction between immutable records, such as historical transaction logs or past social media posts, and mutable streams that evolve over time like live email inboxes or gaming profiles. Unlike traditional protocols that provide static snapshots of data at a specific point in time, PDPP adopts a streaming approach to capture how personal information changes dynamically. This is achieved through the use of cursors within manifests that allow clients to track new records as they are appended, while also supporting tombstones for deleted items to maintain an accurate history without requiring constant re-verification of every single record's state.
A significant design decision highlighted in the discussion was the deliberate avoidance of a canonical data model for common entities like emails or bank statements. Instead of enforcing rigid definitions that might hinder adoption across diverse platforms, PDPP allows providers to define their own schemas while remaining interoperable through optional shared mappings built on top of existing standards like Schema.org. This flexibility acknowledges that different organizations may have unique ways of structuring specific data types and aims to reduce friction for users by letting clients request access based on the actual structure provided by the source, rather than forcing a one-size-fits-all format. The protocol emphasizes clear consent semantics where authorization servers must distinguish between enforceable technical rules and unenforceable client claims regarding data usage purposes or retention policies, ensuring transparency even when certain promises cannot be cryptographically guaranteed.
The conversation also delved into complex challenges surrounding identity management and trust in an era of AI agents and decentralized data collection. Participants debated whether a unified global identity framework should be baked directly into the protocol or layered on top as an extension to avoid becoming too opinionated early on. Concerns were raised about spoofing, where third-party connectors might obscure the true origin of data, potentially leading to misuse or harm if verification mechanisms are not robust enough. The group explored solutions such as live signing of data points during collection and the use of zero-knowledge proofs to verify provenance without revealing sensitive details, suggesting that while a strict identity layer is valuable for high-stakes scenarios like medical records, lighter-weight metadata might suffice for personal assistants accessing one's own notes across platforms.
In conclusion, the working session underscored the importance of balancing rigorous verification with practical usability to prevent users from becoming risk-averse toward data portability tools. The team recognized that different use cases require varying levels of trust and proof; therefore, a flexible framework capable of supporting both simple personal access and complex cross-platform aggregation is essential for future scalability. As AI agents begin consuming massive volumes of generated text alongside human interactions, the protocol must evolve to handle these new data patterns without losing sight of user control. The discussion ended with an invitation for community members to share specific edge cases and use cases that have not yet been considered, aiming to pressure-test the specification against real-world scenarios before finalizing the governance model in subsequent sessions.
Read the full video transcript
Mhm.
>> Mhm.
>> Hey everyone.
I think we'll take a couple of minutes
and then
just jump right in.
Hey Sarah, good to see you again.
>> Hey Tim, great to see you.
>> Thanks for joining.
Um
So you you you are
transitioning from Prolific into a more
general data portability problem space.
Is there anything
in particular that you're excited about?
>> Um so I actually think I think I'm I'm
kind of headed towards provenance in
general and like payloads that are
moving across the internet in general.
Um I think I might end up doing that
from the lens of like like controls of
internet traffic. I'm talking to
a major player who you probably probably
guess who who it is who controls a bunch
of internet traffic who has interest in
in brokering that. Um
But yeah, maybe at a different time we
can talk about the kind of like who has
stake in what parts of this and it's
been a really interesting exploration of
the economics and the various stakes
that different players have on this
space over the last few weeks.
>> Very cool. Yeah, I would love to talk
about that. I looked a little bit into
um sort of CKTLS and connecting the dots
between somebody who wants
you know, proof of provenance or
whatever and a regular person. Um hey
Anna. Hey Justin.
>> Hey Tim.
>> Um I think we can just jump in. I don't
know Anna if you wanted to
um, kick anything off here I can just
throw up the slides.
>> Um, no, just excited for the second
week. Uh, good to see everybody. Yeah.
>> Great.
Okay, 1 second.
Okay, so this is the second session
um, of four sessions where we are sort
of walking through the
um, personal data portability protocol,
PDPP for short.
And
um, I think Anna said it well last week
that what we're really talking about is
the language of data portability and how
can we express um,
what we need to to make data portable on
the internet.
And
if you want to see the recording from
last week or just read through the
session notes, you can find those
through the GitHub. Um, if you can't
find it, just ping me in Discord. I'm
happy to share that.
And
um, we talked a little bit last time
about
sort of the framing of PDPP and the
overall architecture.
Today we're going to start to get into a
little bit more of the technical details
going into how data is modeled
and sort of communicated from data
source providers
um, and then how clients can request
access to data.
Next week we'll get more into
how is access itself modeled and stored
and how are queries served. And then
finally in the fourth week, we will talk
about um, sort of how the protocol is
governed and participation in the
protocol. And we'll just go through some
of the key open questions.
So, going back to um, last week just to
recap
the the architecture in terms of sort of
the flow from the client's perspective
is basically standard OAuth. Um, a
client has a token which is bound to
in our case a consent artifact with
finally modeled data
um
permissions. So, we we kind of sneak
inside of the token something called a
rich authorization request payload
which
pretty much defines exactly what the
client is allowed to access. And of
course for that to work the data needs
to be modeled appropriately and the
server needs to know how to like work
with that and get to the data.
So,
some of the primitives involved are how
do you actually define a record of data?
How do you
create the language for clients to
request access? That's what we're going
to talk about today.
And
then how do you store the access and how
do you query into that?
So, drilling a little bit into
these three concepts, the record model
um the data source manifest and the
selection request.
The record model is sort of the core
building block. It's I have a piece of
data whether that's a post from social
media or a transaction from my credit
card statement. Um or my gaming profile.
And that single piece of data is
defined as a record in PDP
and that's kind of where you start to
define the schema or how is data
um
modeled and expressed? What are the
what are the types of the fields within
the data?
And a manifest is then how do you take
that record and package it up into
um
a collection which is called a stream
where there can be ordering of records
within that collection
where you may want to express particular
semantics about records in the
collection.
Um for example,
if you need to know when something one
data was created, here's the specific
timestamp field that you would look at.
The manifest kind of describes all of
that. And then the selection request is
not only the syntax for how does a
client ask for
access to data, but the rules that go
along with that. And
both the rules for the client and the
rules for the server, that's
conforming with the protocol.
So this is what a
what is a stream like a very simple
stream might look like where or sorry a
record might look like
where the record is defined as part of a
collection called a stream. In this case
it's a collection of messages.
And this particular
record type is pretty simple. It just
defines here's a conversation that this
message came from. This was a message
from a user perhaps as opposed to an
agent. What did the user say and when
did they say it?
So
yeah, this basically can just be
expressed as JSON in most cases and you
could define the schema for this as JSON
schema. And I think it's worth making a
distinction between
maybe when was the record emitted or
known within the protocol. That could be
like a timestamp or called emitted at
versus when was the record itself
created. So maybe
I have an email from many years ago and
there's an important timestamp
associated with that email. When did I
write it? But when did it actually
become part of
the data source in the protocol?
So there
those could be used for different
things.
Some records can carry blobs. So for
example an email might have images or
videos, and
basically, what you would do is you
would just
um
create a blob separately, and then a
reference would ride
um would be attached into the the record
here, and would be resolvable
externally.
So, one of the key design decisions that
we've made within PDP
is that
unlike some other protocols, for
example, in open banking
um where you make a request for data,
and you get back a response, you're just
getting the current snapshot of the
data.
And if you want to understand how data
changes over time, or what has changed
since the last time you act you asked,
there isn't really an affordance to do
that.
Um I think Plaid is an interesting
example in the market, where they
actually moved away from sort of a
static point in time uh query model to a
more cursor-based, like streaming over
time model.
And that's the approach that we're
taking in PDPP, because we think that
that's actually a very valuable
way to to expose data, um especially
because so much personal data
um
kind of decays and is is sort of rapidly
It's almost like it's alive. Like, every
day you get new emails in your inbox, or
every day you're performing more
activity on social media. And so, how
that's changing over time is really
important, versus maybe like um a single
snapshot of your data
that could become outdated um fairly
quickly. So, PDP, in order to
accommodate streams, has a bunch of
features and semantics about, for
example, if a record is deleted, there
there might be a tombstone tombstone rep
representing that that once existed and
no longer exists.
And I think the other
yeah, note about this is
if you're granting standing consent to
data, so
I want to give a one-time
authorization to some client application
to access my financial data whenever it
it wants to or to access my medical
records or social media posts whenever
they want.
Um that could create value for me as a
user of that product.
And in order for that to work, um that
application is probably going to need to
read new data over time and fresh data.
I think something that we've
learned in working with a whole bunch of
different types of personal data
at Open Data Labs and InnoVint,
is most personal data is actually
mutable,
meaning
you see new records all the time, but
the records that you get typically
aren't going to change. So, that could
be
um you write that Slack post, you could
edit it, but most of the time you don't.
And
one of the decisions that we've made is
that
um by differentiating between records
that are append-only versus mutable,
um you can simplify the rules that
client tooling and at the server
um has to play by for the majority of
the data.
For example, if you can assume that this
record is never going to change, then a
client would never need to check again
to see if it has changed.
Some data types um
are expected to change.
My LinkedIn profile is going to change
over the course of my career.
And so, it's important that we can model
mutability.
Um one simplification that we could make
in the protocol is to just say that all
data is mutable and that reduces
um, sort of the different rules that
tools have to follow and um, that
conformance requires.
And so, this is kind of an optimization
and we're still weighing um,
what the right side of that scale is.
>> One perspective I'd be curious to hear
from Caleb. I don't want to put you on
the spot, but I know you work on kind of
data exports more from the platform
side. Um,
what do you think of like when you think
about creating a personal data export,
do you think of it as the historic dump
of a user's data is pretty much
immutable or are you often like updating
different aspects of it?
>> Usually immutable.
But,
now I'm thinking about
this mutable state running things
through my head, so
yeah.
>> Cool. Um,
so here's just a very simple manifest so
you can have an idea of what that looks
like.
Um, we're basically defining
what is this data source called
and what streams does it contain within
those streams?
Um, what are the schemas meaning what
fields do they contain?
And just some semantics that this is a
um, mutable stream.
Like here's where you can follow
um, new records over time by looking at
this field as a cursor.
Um, manifests actually can express a lot
more semantics than this and in PDPP,
um, some of them are optional. So, the
degree to which
you can sort of make data filterable and
rich and meaningful, um, just depends on
how hard you want to work to bubble up
all of those different uh, source
semantic details.
Maybe the most central design decision
of PDPP
is that
there is no canonical data model for
what [clears throat] is an email, what
is a social media post, what is a bank
statement.
Um,
I think people are probably familiar
with things like schema.org and other
protocols including the data transfer
project.
Um, they're designed around
a common definition of a particular type
of data.
Um,
we're we're making the choice to
kind of meet the data where it is.
So, if you imagine the long tail of data
on the internet, a lot of it
is probably fairly narrow in terms of
the domain that it is defined in. There
may not be
um,
a bunch of data providers that are all
providing the same kinds of data. There
could be differences between how
different
providers model different types of data.
Um, some might have more rich data
models than others.
And I would say the key trade-off that
this comes with
is if you wanted to, for example,
um, aggregate all of your transactions
across different banks and credit card
statements, you would then have to
understand the schema for each one of
those.
Um,
however, we're not saying that you can't
create a shared schema. And there's also
nothing preventing you from creating
another shared schema that sort of sits
on top of
the different banks uh, schemas and
defines mappings across those. So, you
could imagine something like
um, how Plaid sort of defined a common
um, schema over existing
provider schemas, that could definitely
be built on top of PPPP.
And
I also think it's interesting that now
that
AI agents are becoming more ubiquitous
and they're able to work with schemas
very easily,
the cost of needing to understand
you know, the next marginal schema
may be approaching zero over time.
And so I think this is a bet that we
feel pretty good about.
Um
And we have seen examples,
I think, of where
trying to
define in too much detail or with too
much abstraction,
like this is what this type of data
looks like, can be a pretty big
impediment to adoption.
Um so we're just taking the opposite
approach and
um I guess we'll see how that goes, but
I feel good about that.
Okay, so now we're moving into the
client experience. How does a client ask
for data which is in some resource
server
that is PPPP conformant.
And
I think it's important to recognize that
um
it actually starts with the client. It
doesn't start with a user or the data
source provider. The client is basically
able to
ask for access in sort of the same way
that in OAuth, a client can ask for
access to a Google's Google users Drive
account or Dropbox users storage.
Um
this just reduces some of the friction
in the process
so that the client application that
wants access can can initiate the
process.
And
what that looks like is a request
where the client needs to specify
um not only what data
do they want access to, specifically
what streams and fields within
um, the data, but also
what um, purpose are they requesting
access for, what commitments are they
making
um, about how the data will be treated.
And
we'll talk a little bit more about this,
I think.
This is where we start to see PDP is a
bit opinionated about what it means for
data to become portable, and we really
want to
make this work well for end users, and
we think that
um, with enough control
authorization servers can do better than
just say like in in OAuth, you just see
something like this application wants to
use your account, and as a user that
could be a little bit confusing.
Um,
maybe one detail here to point out is
clients can actually ask for
optional access to data. So, in this
example
I I need the top artists for this user's
data. If they're if they're interested
in giving me tracks that they've saved
then I can use that in the experience
that I'm creating for them,
um, but if not, I can live without it.
And then the user in the UI could
indicate whether or not they want to
share that data.
So,
I have one question. Sarah, I see you
have a question. Do you want to jump in?
>> Uh, sure. Yeah, thank you. Um, is it
okay to ask a question now, Tim?
>> Yeah, go for it.
>> Um, so this was I was dogfooding a
little bit the other day, and I I put
this on GitHub as an issue as well. Like
the one the one thing I wondered is like
is there is there a representation or
semantics around inventory? Like, um,
should the client know what the entire
like corpus of streams available are by
querying the resource server? Is it
Should there be a way to know that or or
you have to come in knowing what you
want?
>> No, I think that's a great question. I
think um
it's a little bit of an open question
that we want to figure out this month.
And my default answer to that question
is
a client shouldn't be able to know
all of the data that a user has. That's
data in itself.
Like you can imagine if your entire
digital life is connected into some
single personal server,
then learning about what's on that
server is already pretty revealing. So,
I think in the sense that um
like many APIs
will define scopes in OAuth. Here's what
you can access. There are also scopes
for being able to see what data exists
that you or being able to learn what you
can and subsequently request access for.
So, I think directionally that's where
we want to go. I think the current spec
may not fully
like have all of that written up.
Um so, PDP is pretty clear about there
being maybe these three different
categories of promises that
need to be made when consent is given to
data.
And the first one is easy. Anything that
the protocol can enforce
um
like from the user's perspective is
clear. Okay, I'm granting access to
um these fields within my my emails. And
I trust that this authorization server
to enforce those rules, and those
promises are sort of guaranteed
implicitly.
Um but then there are promises that
the client could make about the data
that the authors are authorization
server can't necessarily enforce, but
that should still be communicated
clearly
and that the user should still
be able to consider. Some of those may
be
machine readable. For example, what is
the code that expresses what the purpose
for the use is?
How long will data be retained?
Obviously,
the authorization server can't control
when data gets deleted on
the client application
um server, but that should at least be
sort of communicated clearly.
And then some claims by the client may
not be programmatically consumable. They
could just be messages to the user.
Um we're only going to use this data for
XYZ.
And
it's important that
um the authorization server makes it
clear that these are things that the
client is saying. They can't be
guaranteed, but
there's like a framework where
those claims need to be
um like clearly denoted and
hopefully this helps um users understand
sort of the terms that they're agreeing
to with clients who are requesting
access.
We also have this sort of special case
called out in the protocol
where
just because of the nature of AI
training and how it's really hard to
sort of untrain
um your data out of
say frontier LLMs.
Um we really want that to be an explicit
consent option in this particular flow.
So, if a client wants to use data for AI
training, um
at the moment in the spec, that should
be made explicit.
Um the spec that it doesn't say how
visual design needs to look in the
authorization server, what copy needs to
be used,
what visual language or layout needs to
be used. It's more about um
clearly distinguish making a distinction
between
what the unenforceable client claims are
and the sort of protocol enforced terms
are.
Um yeah, so OAuth basically just
leaves it open. Everybody says this app
wants to access your account, and that's
it.
So, we've talked about some of the key
design decisions
um related to
modeling the data and requesting access
to the data. And just to recap some of
those,
data is
either modeled as mutable or immutable.
Um there are no canonical data models in
the protocol.
And consent UIs need to have clear
semantics.
So, um I would love to open it up for
some discussion or additional questions.
Um you can jump to the website here if
you want to read more of the details in
the standard itself.
Um there's also a personal server that
you can run if you want to play around
with this. And you can build a data
connector to drop your own data in if
it's not already supported. And of
course we're in the Discord server
um and are happy to to hear from you.
Um so, I guess at this point I'll just
open it up or
And if you have any additional thoughts
you want to share before we shift into
some open questions, feel welcome.
>> Um I have Yeah, actually
Karen, I don't want to put you on the
spot and I know we haven't met yet, but
I think you're from the I coming from
the IEEE side, where I feel like you
have a really interesting like standard
setting of
the internet, of Wi-Fi, of Ethernet. And
I think that some of the questions that
Tim is surfacing are
on like
uh kind of how opinionated should a
standard be, and how much should be like
technically enforced versus legally
enforced. So, for example, the tradeoffs
of um stating
uh this is what the data will be used
for versus like cryptographically
enforcing it. So, I'd be curious how you
all have managed the tradeoff of like
yeah, basically how should how how
opinionated should a standard be.
>> Well, in first things
in the standards development process
it it's based upon the group that is
developing the standard in terms of the
content.
Um personally, I don't like a standard
to be too opinionated. It it should
provide a framework
for how things should operate.
And in particular, that framework needs
to be structured so it's safe and secure
um
and and
transparent to all who are trying to
implement it.
And and that interoperability, I think,
is is is very important when you're
looking at a standard. Um
But in you know, in terms of the the
protocol that you're trying to build
here
you know, a couple things come to mind.
I mean, is there a standard set a
dataset
for the information to begin with?
I mean, because I think you know, if if
everyone can agree that in in a a
digital identity environment, there's a
there's a
standard set of data elements.
I mean, others can be ad- added to it,
but there should be a standard set. You
know, your name or your address or
something
>> [clears throat]
>> um that is that is always common amongst
um all of the various um
applications that are using a digital
identity.
I think that would be very important to
note because then, you know, what you're
trying to do in in terms of the
portability of things, it becomes much
easier to say with the standard set,
here's how you can actually move it
around and do things.
And you may have already talked about
it. I was more in listening mode trying
to learn,
um, than anything else right now.
>> No, I think that's a great point. Like
it, um, I think one of Tim's earlier
slides kind of is looking at some of
this trade-off, right? Where there is
no,
um,
kind of, uh, for example, like one
application could call something home
address and another one could call it
just address, right? And because of
that, then someone could actually have
the right information to make it easily
portable, but it might not be
immediately obvious to, the second or
third application because the data is is
kind of named something different. Um,
yeah, that's a really good point.
>> Yeah, I mean, I I,
you know, in in a past life I I was
involved with trying to,
um, manage a lot of data in disparate
systems
and came across the fact that we had
similar data in all the systems called
something different. Um, and it it took
quite a bit to come up with a a flat
file with common elements that could be
used to populate all the databases.
Um,
>> [clears throat]
>> so I'm thinking, well, you know, this
could be another area where, you know,
you can indicate as part of what you're
developing, these are the common fields
that that should be, um,
defined, um,
and and and, uh, implemented in any kind
of digital,
um, identity environment.
Now, it might already exist, I don't
know. Um,
but, you know, somewhere, somehow there
has to be an agreement as to the the
basic elements in this all.
And then what the definitions of
taxonomy that everyone's using.
>> Yeah, I think um
I So, to some extent I think it probably
depends on
the domain. So, within certain domains
interoperability
is going to be very valuable and there
should be
um a lot of overlap between
what different providers would model in
the data.
In some cases
um
there may be data that's unique to a
specific company or specific
situation.
And it might be difficult to anticipate
how to model that. And so, I think
kind of what you're saying about
creating
a framework
could could offer a path for
that particular company or users
interested in that making that data
portable
to define what is the data type
um that
could sort of be the standard for
interoperability there.
I think maybe we need to think a little
bit more about
um how to balance
the unique shapes of data in different
platforms
uh and what those differences are with
sort of cutting down the friction
in
being able to import and export in
different systems. So,
>> Well, and it would be useful in the in
the beginning
that you can you can say, "Okay, for
address we mean this."
You know, and if you have four or five
common elements, it it doesn't preclude
others from adding to that for their
particular application or need. But, at
least all systems would recognize the
four common elements.
So that provides you with that that
pathway to portability. Um and that
pathway to to use, you know, the the
protocol you're trying to to develop
here.
>> Yeah, and there may be existing
resources or maybe like schema.org um
data models within DTP.
We may be able to better support
compatibility with common definitions of
data types and make that a sort of
first-class path within the protocol.
>> Yeah, I mean I think that would be very
useful and then and make your protocol
then very
um
attractive
for people to use because it it's built
upon common elements.
>> I think one place where my mind goes
from this too is um
to what extent is that uh translation
layer built into the protocol versus
something on top of the protocol which
is kind of consuming and translating the
different schemas um especially thinking
about all the different um types of data
that could come in um
I know actually one perspective that
could be interesting. Melbourne, I know
you've worked with a lot of coding data.
I would be curious. Oh, bye Caleb.
Thanks for joining. Thanks for joining
super early in SF and now hopping on an
on-call issue. But um Melbourne, like if
there was a format for agentic coding
data and you were using would that be
the same format as like agentic coding
data from Claude Code and from Codex or
would it vary between platforms?
>> Sorry. So one of the things that I mean
this is a very important discussion and
it's something that we also grappled
with
to standardize the kind of data that
we're actually collecting.
Um
So, there are two problems here. One is
agentic coding, which is a content
piece, and the other piece that we're
talking about standardizing is the
identity or identification of certain
elements of the data contributor itself.
Right? So, what we did is um
we to solve the first problem, we
basically narrowed down the
uh scope within which the data
contribution was happening. So, we put
up a bounties
to solve certain problems. So, every
data that gets solved for that
particular problem get gets attributed
to something similar over there. We can
use some some kind of semantic um search
semantic uh attribution to basically do
that. The other bit about the identity,
what we did is in the application
itself, uh we maintained a um a way so
that only one identity pursued
throughout uh different sessions. So,
for we had three platforms. One is the
um one of one of our web platform where
you could actually look at how you're
doing, what kind of data you
contributed. One was the contribution
itself happening in a in a VS Code
environment or a VS Code extension,
basically. So, the login into the VS
Code extension and the login on the web
platform was the same route. So, we
basically redirected that way to
basically get it. So, the identity
always remained the same of the data
contributor. And what we did is we
created a wallet, which was actually a
Vana wallet that we created for the
users over there
um the moment they signed up. And it was
a completely
uh account abstracted wallet that we
created. So, that wallet becomes that
one source of
not I would say truth, but I would say
one source of identifying the user.
That's kind of how we practically
implemented it at that time, uh since
there was no standard existing. Uh but
yeah, that's if that helps in basically
putting a mental
model in place, then yeah.
>> Yeah, yeah. It's sort of like there's
some data which is shared across
platforms and environments, but then
there's other data that ends up being
pretty specific, right? Of like, okay,
this particular coding task was trying
to accomplish this would be super
unrelated to like an export from Airbnb,
right? Or an export from another data
source.
Um, interesting.
>> One another thing I wanted to add is I
was working for with another project
called Decide AI.
So, these guys initially for data
contributions, those guys basically did
is they solved the identity problem
first. It's like give everyone an
identity first.
Onboard people, get them an identity.
So, that one unique identifier of the
data contributor versus a and then you
basically have to have plugins for other
other um,
platforms. So, if you For example, if
you're integrating with Airbnb, so there
needs to be custom integrations for each
of these platforms that we're collecting
data from. Becomes cumbersome, but yeah.
It's a problem that needs to be solved
because unified identity is is a touchy
topic politically as well because it can
also be misused. So, yeah.
>> Interesting. I'm just thinking about
if you don't have a unified identity,
like what are the key problems? And
let's say you're collecting data from
multiple sources, and they all have some
identity information associated with
those.
You have to do some work to tie them
together.
Um, are there particular problems that
jump to mind
for you with that? Like somebody could
use different email addresses, or you
may need to verify
identity multiple times.
>> What are you saying?
>> the first thing that comes to my mind is
more security.
I mean, you're dependent upon mapping
things correctly to the right spot.
Um and which leaves a lot of openings
for mischief.
>> That makes sense.
I think something that the protocol
hasn't yet solved for in the current
version, which we're still working on,
um
is
let's say
a plat- let's say Airbnb
is conforming with PPP and has an
authorization server
with identity associated with Airbnb.
To some extent, as a client,
I if I know it's Airbnb, like I can
trust
what that identity is and what the
implications of that are.
Versus if somebody in the community
builds an adapter
um for for Airbnb, like a data
connector,
um
maybe if that data isn't coming directly
from Airbnb, but it's been collected or
exported another way,
then
the assumptions that I can make about
the nature of the data are a little bit
different. And so maybe there is a
maybe this is where provenance comes in
more, Sarah, like having more of a
um
whether it's a proof of provenance or
there's some trust elements um
or maybe like a trust registry, similar
to DTI's trust registry,
maybe these these components start to
become more relevant. Um so maybe it's
something that we can explore a little
bit more
um
in in this iteration of the spec.
>> So something that's in my mind is like
is this a one-way door that needs to be
solved like right at the beginning of
launch or can it become can like it
feels to me like there will probably be
some kind of like semantic matching as
well as like being able to match across
like a strong identity frame framework
that needs to be supported always.
I don't know, maybe that's that's that's
not true, but like it feels that maybe
the identity framework can be layered
on.
Um
uh because we do a little bit of work on
corroboration and trust uh signals that
proliferate um I'm yeah, I I think it's
like not non-trivial lift, I would say.
I don't know if others feel feel
different. Um so yeah, I'm just thinking
about like one-way door and two-way door
decision points on this.
>> I think that's a good point and
when Anna and I were working on data
collectives and
in that context um
provenance is pretty important. Like if
you're pooling your data with other
people
and you want some
some evidence that your data is worth
something or that it fits the the
collective
like how is that expressed? And I think
um
to me that's it seems like more of a
a future's decision that can be layered
on later on.
Like just attaching
um
a ZK proof or whatever it is that can be
verified doesn't have to redefine the
the data model, but it can extend it or
it could be an extension to the protocol
like a profile over the protocol.
>> I think the idea um Karen that you're
bringing up around mischief is like
really interesting to explore. Like what
is it what does mischief even mean,
right? And like what provenance
guarantees should be baked in at the
protocol layer versus of like an applic-
sort of yeah, where exactly is the
trust? And I think that today with PDPP,
we've really relied on um
actually being pretty neutral towards
okay, this
this is expressing this, but we're not
actually verifying is this checked? Is
this coming from uh we can know this
came from this identity, but if somebody
is like using a a data connector um
and connecting
uh
say their their ChatGPT data via a a
data connector, you don't actually know
that it came
directly from ChatGPT, right? Unless
their support OpenAI supporting PDPP.
Um
yeah.
>> And there's And there's so much spoofing
out there.
>> Mhm.
>> I mean, so how how do you know?
>> [clears throat]
>> And I and I know that's more and more of
a concern from um a lot of places.
Uh and um are the Is the data you're
getting actually
um a fake?
Which then leads to all kind of mischief
and and harm potentially.
Or is it is it actually legitimate and
and reliable?
>> Yeah. And I think a big question too is
like who decides what is legitimate and
reliable, right? Because like to one
person like you could have an account
that's um
a real Spotify account, but has had 2
years of history that someone connected,
but it could be that somebody bought
that on the dark internet. And it while
it's a real account, it's not actually
that person's, right? And so I think
that it also gets into these interesting
questions of like what actually is the
guarantee you're looking for? Is it that
this data came from this platform
exactly? Is it like this user own own
this particular account and connected
it? And I think like where I lean is
actually being kind of more neutral, but
adding more flexible ways of putting
metadata onto it, so you can know, okay,
it came from here, this proof is there,
but not trying to make um too strong of
a claim because it it seems like
nearly impossible like even just making
the claim we know this data is
legitimate can so many people can
interpret that different ways.
Yeah.
>> Yeah. I mean and
you know, people are becoming risk
adverse to a lot of things.
So in in looking at the protocol, you
don't want them to become risk adverse
to using it.
>> Yeah.
>> You want to make this advantageous for
them.
So
just thinking about you know, going back
you know, you have the common elements.
I mean if you have your name and your
address and and you determine whether
it's your home address or something,
everybody has a name and address and
even a telephone number that can be
verified.
So you you you start with a foundation
of trust.
Data elements that can be verified.
Now you you may not have to build that
into the protocol, but you can note that
these are common data elements and
they're verifiable within the country
that you're working in.
I mean that that might help a bit.
>> Yeah, I mean
>> Sorry.
>> No, go ahead.
>> Also yeah, this is one thing that we
basically thought of tackling as well
with our application. So like I
mentioned earlier, it was a
um
extension on VS code. Um so what we were
tracking was as users and you know, run
a program on the terminal, we used to
know
we used to collect the output of that.
Is it an error or is it like did it
execute successfully? So what ended up
happening is we were we were essentially
collecting the proof
live.
Right, and attributing it to the user.
Right, so now we've formed unique
signatures for each data point as it got
recorded.
So, that kind of a live collection
um actually helps in the sense even the
metadata like you mentioned Anna can be
attributed to some some kind of an
action
that actually led to it. So, if the
protocol can actually I don't know if
the protocol can enforce it but
definitely the value of such a data
becomes much higher because now it's
verifiable.
Right.
So, yeah, that's kind of how we
basically built our product around this
data collection, but yeah.
Just to
share.
>> And I think
>> to get to that one on kind of like real
time like if you can have be collecting
that like real time
um
verification and metadata of like, okay,
this just happened. You've got some
record that it happened. It's sort of
signed in or verified in some way and
just have that built in, then it it kind
of lets you um
almost on top of that build other
verifications, right? Where like then if
a bunch of stuff is missing, okay,
that's starting to look a little bit
weird, right? And kind of having that
automatically um writing back in.
Sorry, Tim. Go ahead.
>> No, I just think it's it's interesting
because
like the set of all possible use cases
and the set of different levels of
verification and types of verification
that you may want to me seems really
varied and diverse.
And so
building um a framework that
like has a lot of flexibility
to me just makes a lot of sense. Like
what you would need to
like send medical sensitive medical
records from one medical provider to
another versus what you would need in
terms of verification or somebody just
conveniently accessing their own notes
which the protocol could enable
um
or maybe I have notes in two different
platforms that I just want to access
them with a single local personal
assistant agent. I may not need
verification for that. Um because it's
my data and I know where it comes from
and I'm I'm not using it for anything
um that requires verification.
And so I think if we
pick
if we pick a side and only solve for
that one side, we probably lose
um
a lot of valuable use cases. If we don't
have any path for verification,
then important verification use cases
are just not possible. And if we
add like really rigorous verification in
the in the protocol,
then that could cut out
uh situations where I may not want to do
the work to like create proof that the
data is valid because that's not
actually needed. So
thinking of this in terms of
layers and also
creating bridges to other technology and
other protocols that solve some of these
problems
feels like the direction that I would
naturally orient to here.
>> Well, I'm you know, I'm thinking
actually it might be interesting just to
try and try and document a variety of
use cases
and then see if you could how the
protocol might work with it.
>> Yeah, I think that's a really important
point. Um
and
like Anna and I have worked
in a pretty wide with a pretty wide
types of data and been thinking about
different use cases, but probably not
all of them and definitely not all of
the important ones.
So I think that's a good call out. Um
to to really like pressure test the
protocol, we need to sort of pretty
exhaustively
go through what are the the weird edge
cases we haven't thought about or what
are the different um data providers or
different consumers of data or clients
that we haven't looked at directly. If
you guys have any
specific use cases in mind or any
references,
um we'd love to hear those. Like
like here in in the chat or later on.
Um
yeah, I think that's I think that's
important.
>> I think too, especially with um
just how much the internet is changing
with a lot of the kind of agentic use.
Like I exported my cloud data recently
and it's like 27 million tokens worth of
text and it's just like a crazy amount
of data, right? And so also thinking
about the use cases from the perspective
of like
what's that going to look like 3 years
out, right? Probably my export is going
to be
I don't know, like 500 million tokens,
like a billion token like it's you could
just going to be a massive amount of
data and thinking through like
what does that then mean? Um what what
are context windows going to look like
cuz I think often it's going to be that
you're using PDPP to to kind of grant
access to past data into um an LLM. And
so thinking through those patterns, um
both for like
what is the current state of data and
how it's moving on the internet and
especially where things are headed just
because things are kind of changing so
quickly, too.
Um
I think that's all. I guess I I'll pause
if there if there any other questions um
people want to ask or or thoughts or
comments.
Um let me just pause for a minute or so.
>> Uh maybe one follow-up comment
um on the agentic
like
like frontier that we're in. I notice
that I actually don't know
within my within within my own coding
agent data now, I don't always know
when it was me that said something
versus another agent like driving
another agent.
The lines are starting to blur more and
more and as I delegate more and more to
agents, it's like
what what is my data? What is that
agent's data? Like it's all it's all my
data, but making sense of it
may get harder. Um so I think that's
interesting.
>> Yeah, I actually was doing the breakdown
on my chat GPT data uh all of this. So I
had 6 million tokens in chat GPT and
only 1 million of them were tokens I
wrote and then 3 million were generated
by AI and 2 million were tool calls.
Right? And so then it's also interesting
to think about like, "Okay, the majority
of data is like my interactions with AI
and the AI saying something back." And
then how do we grant access and make
that portable as well? Um
Okay, well thank you everyone for like
joining and so actively participating in
the discussion. Um I hope to see you all
next week. Um and yeah, we'll be on
Discord um and yeah, we'll see some of
you too, I know, in Geneva as well.
>> Yeah, thank you everyone.
>> Wonderful. This was a great discussion.
Thank you.
>> Yeah, what a pleasure. Okay, goodbye.