Flesh out more about what's going on

parent 9fa3e0c5
......@@ -139,3 +139,106 @@ That's all great, but how is this different than any other ActivityPub
instance?
How do we even know that things were sent securely?
If we look at the *Id:* field, we'll see something like the following:
: magnet:?xt=urn:sha256:Cvy4hoVEsY7n3T2wf4306IhhBS1CV03pNuLtMOR73xc
: &ek=_T8EGDBegDdmMdqRG4Lyd8zFto0cmck4FoaRzsXcM08
: &es=aes-ctr
This is the "id" of the object, which is the address from which we can
retrieve the object.
In contemporary ActivityPub servers, this is generally an http(s) URI
scheme.
The message that is delivered to an actor's inbox usually has this
"id" attached to it, so we know where it lives (and can verify its
contents).
But there is no requirement in ActivityPub that the id of an object
be an http(s) URI, only that it be a URI.
In http(s), content is generally "live"; when you request the object,
some specific server is responsible for handing it to you and is
the authority of what belongs there (which could always change).
However if that server goes down (or perhaps if the domain pointing to
it expires or gets transferred) you might not be able to retriev it
any more.
In other words, the http(s) scheme represents a kind of [[https://en.wikipedia.org/wiki/URL][URL]].
URLs have some advantages, but as it turns out, there are other kinds
of URI schemes out there.
One of these is called a [[https://en.wikipedia.org/wiki/Uniform_Resource_Name][URN]], which is fairly well described by
its Wikipedia page:
#+BEGIN_QUOTE
URNs were conceived as persistent, location-independent identifiers
assigned within defined namespaces, typically by an authority
responsible for the namespace, so that they are globally unique and
persistent over long periods of time, even after the resource which
they identify ceases to exist or becomes unavailable.
#+END_QUOTE
Alice could host a picture of a cat live at =https://catpics.example/pics/mycat.jpg=,
but that could always go down.
If the cat picture became very popular, Alice would be responsible
for paying for all that bandwidth herself.
But there's a category of URNs that are "content addressed"; in other
words, if the sha1 hash of the cat photo Alice wanted to share was
=dbe5b3e2aabde97aefdc5b605cacd0ce8210c203=, Alice could share the URN of
=urn:sha1:dbe5b3e2aabde97aefdc5b605cacd0ce8210c203= with Bob,
and Bob could ask his peers (which could include Alice) for a file that
matches that hash.
Once a Bob finishes downloading a file from that peer, Bob can verify
that the hash of the content matches.
This is a totally valid type of URI, even though it's not what many
users of the web are used to.
And it turns out, we can use these as the identifiers for objects in
ActivityPub, and then they can live anywhere.
But wait... that's not enough.
We want the network in general to be able to help distribute objects
to anyone who asks for them, and yet we also want to keep posts
private between their intended recipients.
We can encrypt the file with a symmetric key we share /only/ with
the intended recipients, break it apart into regularly sized chunks
so nobody can guess which file it is based on its filesize, and then
those encrypted chunks can be safely shared by the whole network...
but only the recipients of the key can unlock its content.
The [[https://github.com/WebOfTrustInfo/rwot7/blob/master/topics-and-advance-readings/magenc.md][Magenc]] writeup explains how it does this by extending the
[[https://en.wikipedia.org/wiki/Magnet_uri][magnet URI]] scheme, composing together both the content URI (or a
manifest chunk that points to the rest of the chunks) with the key
into a new magnet: uri.
(This idea isn't new; it's been done for quite a while by projects
like Tahoe-LAFS and Freenet.)
If we look again at the *Id:* header, now this starts to make a lot
more sense:
: magnet:?xt=urn:sha256:Cvy4hoVEsY7n3T2wf4306IhhBS1CV03pNuLtMOR73xc
: &ek=_T8EGDBegDdmMdqRG4Lyd8zFto0cmck4FoaRzsXcM08
: &es=aes-ctr
- *xt* stands for "eXactTopic". It's where our initial encrypted
chunk is! (Which might be the only chunk if it's very small.)
Anyone in the peer to peer network can pass this around and help
share it, but not everyone in the peer to peer network knows
what it is (this is also helpful for those who want to generally
distribute content on the network... it can reduce your liability
for passing around content you don't know about, since you don't
know what it is).
- *ek* stands for the "EncryptionKey". Since it's symmetrically
encrypted, it's also the decryption key! We can use this to
decrypt the chunk above (as well as any other chunks it points
to).
- *es* is the encryption suite. Different encryption suites are
possible so we need to know which one. In this case, it's
aes-ctr.
This is all very good and well, but what does it look like during
federation?
* Verify it yourself!
* Problems with this demo
- urn:sha256 isn't actually specified yet, but it probably should be
- At the time of writing, the magenc extensions to the magnet scheme
aren't used by anything in production yet.
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment