Merge pull request #3 from WebOfTrustInfo/master

merge changes

README.md

@@ -21,15 +21,15 @@ The following advanced readings have been prepared as primers, intended to give
 Here are the rest of the advance readings to date:
 
 * [#RebootingWebOfTrust User Story & Tech Concept](topics-and-advance-readings/RWOT-User-Story.md) by Christopher Allen
-* [ActivityPub: from decentralized to distributed social networks](topics-and-advance-readings/activitypub-decentralized-distributed.md) by Christopher Allan Webber ([PDF version](https://gitlab.com/dustyweb/talks/blob/master/activitypub/rwot/even_more_distributed_activitypub.pdf))
+* [ActivityPub: from decentralized to distributed social networks](topics-and-advance-readings/activitypub-decentralized-distributed.md) by Christopher Lemmer Webber ([PDF version](https://gitlab.com/dustyweb/talks/blob/master/activitypub/rwot/even_more_distributed_activitypub.pdf))
 * [Architectural Layering for Decentralized Identification](topics-and-advance-readings/Architectural-Layering-for-Decentralized-Identification.md) by Drummond Reed
 * [BFTKV: Byzantine Fault Tolerant Web of Trust based Key-Value Storage](topics-and-advance-readings/byzantine-fault-tolerant-web-of-trust-based-key-value-storage.md) by Ercan Ozturk
 * [BFTKV DID Method Specification](topics-and-advance-readings/BFTKV-DID-Method-Specification.pdf) by Ercan Ozturk
 * [Biometric transaction signing on blockchain](topics-and-advance-readings/Biometric-transaction-signing-on-blockchain.md) by John Callahan & Virgil Tornoreanu
 * [Blockchain Based Digital Signatures: Admissibility and Enforceability](topics-and-advance-readings/Blockchain-Based-Digital-Signatures--Admissibility-and-Enforceability.md) by Dazza Greenwood
 * [BTCR DIDs and DDOs](topics-and-advance-readings/btcr-dids-ddos.md) by Kim Hamilton Duffy
 * [Credential Handler API](topics-and-advance-readings/credential-handler-api.md) by Dave Longley and Manu Sporny
-* [Data Minimization and Selective Disclosure](topics-and-advance-readings/Data-minimization-and-selective-disclosure.md) by Lionel Wolberg
+* [Data Minimization and Selective Disclosure](topics-and-advance-readings/Data-minimization-and-selective-disclosure.md) by Lionel Wolberger
 * [Decentralized Identifier Tooling](topics-and-advance-readings/credential-handler-api.md) by Dave Longley & Manu Sporny
 * [DID for the 3D Web](topics-and-advance-readings/did-3d-web.md) by Alberto Elias
 * [DID Tooling](topics-and-advance-readings/did-tooling.md) by Manu Sporny and Matt Collier

draft-documents/README.md

@@ -8,13 +8,13 @@ Activity Pub Update | Chris W. | [Draft](https://github.com/WebOfTrustInfo/reboo
 Amira: RWOT Use Case | Joe A. | [Draft](https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-fall2017/blob/master/draft-documents/Amira-SSWOT-Engagement-Model.md) | Thanksgiving?
 Blockcerts Revocation with DIDs | Kim | [Draft](https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-fall2017/blob/master/draft-documents/blockcerts_revocation.md) | 11/10?
 Breaking (Down) the Law | Dazza | [Notes](https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-fall2017/tree/master/draft-documents/BreakingDownAndConnectingLawAndTech) | 
-Certificate Chaining | Chris W. | [Draft](https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-fall2017/blob/master/draft-documents/lds-obcap/lds-obcap.md) | 10/6?
+Certificate Chaining | Chris W. | [Draft](https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-fall2017/blob/master/draft-documents/lds-ocap/lds-ocap.md) | 10/6?
 Data Minimization & Selective Disclosure | Lionel | [Outline](https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-fall2017/blob/master/draft-documents/DataMinimization/Data%20Minimzation%20and%20Selective%20Disclosure.md) | 10/21?
 DCS Triangle | Greg S. | [Draft](https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-fall2017/blob/master/draft-documents/dcs-theorem/The-DCS-Theorem.pdf) | 10/21?
 DID Method Spec Templates | Drummond | [Draft](https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-fall2017/blob/master/draft-documents/DID%20Method%20Spec%20Template%20Definition.md)
 DID Resolver | Markus | [Examples & Images](https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-fall2017/tree/master/draft-documents/UniversalResolver) | 10/27?
 Four Primers | Joe, Natalie, Drummond, Manu | [DID](https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-fall2017/blob/master/draft-documents/did-primer.md) -- [Functional ID](https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-fall2017/blob/master/draft-documents/functional-identity-primer.md) -- [Self-Sovereign ID](https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-fall2017/blob/master/draft-documents/self-sovereign-identity-primer.md) -- [Verifiable Claims](https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-fall2017/blob/master/draft-documents/verifiable-claims-primer.md)
-GDPR | Marta | [Abstract](https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-fall2017/blob/master/draft-documents/GDPR-Self-Soverign-ID.md)
+GDPR | Marta | [Abstract](https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-fall2017/blob/master/draft-documents/GDPR-Self-Soverign-ID.md) | Before Holidays
 Hub Asset Access Control System  | Matt S. | [Revision](https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-fall2017/blob/master/draft-documents/DIF-Hub-Capabilities-RWOT.md)
 Identity Hubs Capabilities Perspective | Adrian | [Final](https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-fall2017/blob/master/final-documents/identity-hubs-capabilities-perspective.pdf) | **Posted**
 Identity Mental Maps | Joe A. | In Process

draft-documents/activitypub-decentralized-distributed/activitypub-decentralized-distributed.md

@@ -1,4 +1,4 @@
-# ActivityPub
+# ActivityPub: from decentralized to distributed social networks
 
 *This paper was written originally for the 2017 Rebooting Web of Trust*
 *summit.*
@@ -39,10 +39,12 @@ client-server model system to a fully peer-to-peer system.
 
 ## ActivityPub overview
 
-<div class="center">
-*This section is borrowed from the ActivityPub standard's*
-*Overview section; if you are already familiar with ActivityPub*
-*then you may skip this section.*
+<p class="center">
+<em>
+This section is borrowed from the ActivityPub standard's
+Overview section; if you are already familiar with ActivityPub
+then you may skip this section.
+</em>
 </div>
 
 ActivityPub provides two layers:
@@ -311,7 +313,7 @@ reasons.
 
 One common problem in federated social networks that support private
 interactions is that a conversation can become fragmented: if Ben is
-posting to private collection<sup id="fnr.5">[5](#fn.5)</sup> she has
+posting to private collection<sup id="fnr.6">[6](#fn.5)</sup> she has
 curated containing both his friends and coworkers, and members of coworkers
 can't see who is in the private family collection, when they
 address to include the family in the conversation they can't traverse
@@ -333,7 +335,7 @@ of knowing who was in the private collection to enable access for.
 
 This is a frequently requested feature in federated social networks,
 so we should ensure that the necessary public key infrastructure is
-provided.<sup id="fnr.6">[6](#fn.6)</sup>
+provided.<sup id="fnr.7">[7](#fn.7)</sup>
 
 ### An easier to use web of trust?
 
@@ -347,7 +349,7 @@ attend and organize, and even more difficult still is learning the
 system.
 While some work has been done in this area (for example with
 [Monkeysign](https://monkeysign.readthedocs.io/en/2.x/) and [Gibberbot](https://guardianproject.info/apps/gibber/)), it would be even better if building your
-trust network was incidental to participating in the network.<sup id="fnr.7">[7](#fn.7)</sup>
+trust network was incidental to participating in the network.<sup id="fnr.8">[8](#fn.8)</sup>
 
 To a certain extent, this could come "for free, with caveats" in
 ActivityPub deployments that exist today, where subscriptions and
@@ -367,7 +369,7 @@ Furthermore, a malicious actor can still trick users;
 a user may believe they are subscribing to
 `https://social.example/alyssa/`, but perhaps Mallet tricked them
 into subscribing to `https://social.example/alyssaa/`
-instead.<sup id="fnr.8">[8](#fn.8)</sup>
+instead.<sup id="fnr.9">[9](#fn.9)</sup>
 
 Happily there are other ways to encourage stronger trust networks.
 Carl Ellison's paper
@@ -402,7 +404,7 @@ of a user,  a user may provide  a public key on their  actor object to
 which only their own computer(s) hold the corresponding private key.
 Other actors on the network may then send an object encrypted to the
 actor's inbox.
-For example, an actor may receive the following object<sup id="fnr.9">[9](#fn.9)</sup>
+For example, an actor may receive the following object<sup id="fnr.10">[9](#fn.10)</sup>
 in their inbox:
 
 ``` json
@@ -446,7 +448,7 @@ tradeoffs:
     network, these kinds of side effects will break.
     The server will also be unable to provide additional features
     such as being able to have server-based indexing of messages
-    for easy search.<sup id="fnr.10">[10](#fn.10)</sup>
+    for easy search.<sup id="fnr.11">[11](#fn.11)</sup>
 
     In a "more peer-to-peer" system (as discussed in the
     Distributed identity section) this becomes less of an issue
@@ -708,7 +710,7 @@ Indeed, even the actor's `followers` is a `Collection` like this!</div>
 <div class="footdef"><sup><a id="fn.7" name="fn.7" class="footnum" href="#fnr.7">7</a></sup> Several decisions need to be made
 when storing signatures on objects which themselves reference other
 signed objects that may mutate, and this is
-[currently a topic of open discussion](https://github.com/w3c-dvcg/ld-signatures/issues/7).
+<a href="https://github.com/w3c-dvcg/ld-signatures/issues/7">currently a topic of open discussion</a>.
 This may motivate more work on
 append only systems and content addressed storage.
 Existing implementations which operate in a mutation-prone environment
@@ -719,19 +721,19 @@ revision seen.
 The latter two options may pose some challenge to highly relational
 systems which were not originally designed with signatures in mind.</div>
 
-<div class="footdef"><sup><a id="fn.8" name="fn.8" class="footnum" href="#fnr.8">8</a></sup> [GNU Ring](https://ring.cx/) is an interesting example of a peer-to-peer
+<div class="footdef"><sup><a id="fn.8" name="fn.8" class="footnum" href="#fnr.8">8</a></sup> <a href="https://ring.cx/">GNU Ring</a> is an interesting example of a peer-to-peer
 social network system where a user's identity is actually their
 fingerprint.  While not the first system to have this concept, it's
 very pleasant to see in action (and the interface is itself
 aesthetically pleasing); to build up your buddy list is quite
 literally to build your web of trust.</div>
 
-<div class="footdef"><sup><a id="fn.9" name="fn.9" class="footnum" href="#fnr.9">9</a></sup> There are an incredible number of [unicode hacks](http://www.unicode.org/Public/security/latest/confusables.txt),
+<div class="footdef"><sup><a id="fn.9" name="fn.9" class="footnum" href="#fnr.9">9</a></sup> There are an incredible number of <a href="http://www.unicode.org/Public/security/latest/confusables.txt">unicode hacks</a>,
 which can trick even the most careful of technical users as well.</div>
 
-<div class="footdef"><sup><a id="fn.10" name="fn.10" class="footnum" href="#fnr.10">10</a></sup> `https://securityns.example/` is an imaginary
+<div class="footdef"><sup><a id="fn.10" name="fn.10" class="footnum" href="#fnr.10">10</a></sup> <code>https://securityns.example/</code> is an imaginary
 json-ld context which is used only as a placeholder for the terms of
-`EncryptedEnvelope` and `encryptedMessage`.
+<code>EncryptedEnvelope</code> and <code>encryptedMessage</code>.
 Perhaps in the future terms along these lines (maybe with better names)
 would appear in one of the other contexts/namespaces that appear in
 this document.</div>
@@ -740,7 +742,9 @@ this document.</div>
 Receiving PGP-encrypted email means that a webmail interface would be
 unable to search through your messages.
 However, that does not mean searching is impossible; some programs like
-[mu](http://www.djcbsoftware.nl/code/mu) / [mu4e](https://www.djcbsoftware.nl/code/mu/mu4e.html) can index encrypted email locally and provide such a search
+<a href="http://www.djcbsoftware.nl/code/mu">mu</a> /
+<a href="https://www.djcbsoftware.nl/code/mu/mu4e.html">mu4e</a>
+can index encrypted email locally and provide such a search
 interface, on a user's local machine.</div>