<p>Hello World!<br><br>I just spoke with a <a href="/tags/us/" rel="tag">#US</a> <a href="/tags/senator/" rel="tag">#Senator</a> office about the <a href="/tags/fediverse/" rel="tag">#fediverse</a> . They're asking for more information to help spread around <a href="/tags/capital/" rel="tag">#Capital</a> <a href="/tags/hill/" rel="tag">#Hill</a> in small bite sized easy to understand pieces. I'm obviously going to give them <span class="h-card"><a href="https://aseachange.com/@elena" class="u-url mention" rel="nofollow noopener noreferrer" target="_blank">@<span>elena</span></a></span> beautiful <a href="/tags/movie/" rel="tag">#movie</a> on the <a href="/tags/fedi/" rel="tag">#fedi</a> (with some light editing which she's agreed to).<br><br>I'll of course show them <a href="https://fediverse.info/" rel="nofollow"><span class="invisible">https://</span>fediverse.info/</a> and <a href="https://fedi.tips/" rel="nofollow"><span class="invisible">https://</span>fedi.tips/</a> which are great websites. I figured I'd give them examples of amazing <a href="/tags/ap/" rel="tag">#AP</a> projects such as <a href="/tags/mastodon/" rel="tag">#mastodon</a> , <a href="/tags/pixelfed/" rel="tag">#pixelfed</a> , <a href="/tags/peertube/" rel="tag">#peertube</a> , <a href="/tags/bandwagon/" rel="tag">#bandwagon</a> , and <a href="/tags/bonfire/" rel="tag">#bonfire</a> ; even things like <span class="h-card"><a href="https://fedimeteo.com/fedi/admin" class="u-url mention" rel="nofollow noopener noreferrer" target="_blank">@<span>admin</span></a></span> .<br><br>I'd love to know from folks any EASY to understand projects that best encompass the Fediverse and explanations of it.<br><br>What are some projects you'd hand to your friends and family that would explain and display to them what we are?<br><br>I'll say this isn't going to happen over night. There's lot of questions around regulations, trust & safety, etc. But I feel it's pertinent to at least get the conversation going, especially considering the current state of disdain for big social media and the impending legislation around these things.<br><br>I'll finally state if there's anyone in this list that does NOT want to be involved with this, that's totally fine and I understand and I can exclude you from the materials I give to them.<br><br><a href="/tags/boost/" rel="tag">#boost</a> <a href="/tags/boostplease/" rel="tag">#boostplease</a> <a href="/tags/government/" rel="tag">#government</a> <a href="/tags/laws/" rel="tag">#laws</a> <a href="/tags/activitypub/" rel="tag">#activityPub</a><br><br><span class="h-card"><a href="https://mastodon.social/@benpate" class="u-url mention" rel="nofollow noopener noreferrer" target="_blank">@<span>benpate</span></a></span> <span class="h-card"><a href="https://framapiaf.org/@peertube" class="u-url mention" rel="nofollow noopener noreferrer" target="_blank">@<span>peertube</span></a></span> <span class="h-card"><a href="https://indieweb.social/@bonfire" class="u-url mention" rel="nofollow noopener noreferrer" target="_blank">@<span>bonfire</span></a></span><br><span class="h-card"><a href="https://mastodon.bsd.cafe/@stefano" class="u-url mention" rel="nofollow noopener noreferrer" target="_blank">@<span>stefano</span></a></span> <span class="h-card"><a href="https://mastodon.social/@dansup" class="u-url mention" rel="nofollow noopener noreferrer" target="_blank">@<span>dansup</span></a></span> <span class="h-card"><a href="https://mastodon.social/@Mastodon" class="u-url mention" rel="nofollow noopener noreferrer" target="_blank">@<span>Mastodon</span></a></span></p>
ap
<p>Concept for discussion: Replacing HTTP Signatures with Bearer Tokens for ActivityPub Federation<br><br>Curious what other people think about this idea. What if federation security was re-worked to use target-assigned <a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Authentication#bearer" rel="nofollow">bearer tokens</a> to authenticate GET/POST requests? This would remove the need for complicated signing schemes and reduce system load under heavy traffic bursts (as no cryptography is required).<br><br>A basic implementation could look like this:<br>1. When instance A (a.example.com) first attempts to federate with instance B (b.example.com), a POST request is made to a dedicated registration endpoint. (for discussion, we'll say it's <a href="https://b.example.com/activity-pub/register-instance)." rel="nofollow" class="ellipsis" title="b.example.com/activity-pub/register-instance)."><span class="invisible">https://</span><span class="ellipsis">b.example.com/activity-pub/reg</span><span class="invisible">ister-instance).</span></a> This request includes fields necessary for verification, including the source domain name, target domain name, and a securely-generated verification token. Other metadata could be included to allow instance B to selectively allow/prohibit federation based on other criteria, but this is optional.<br>2. Instance B makes a POST request back to a dedicated verification endpoint on instance A (for discussion, we'll say it's <a href="https://a.example.com/activity-pub/verify-registration)." rel="nofollow" class="ellipsis" title="a.example.com/activity-pub/verify-registration)."><span class="invisible">https://</span><span class="ellipsis">a.example.com/activity-pub/ver</span><span class="invisible">ify-registration).</span></a> This request must include the target domain name and verification token provided in step 2.<br>3. Instance A checks the verification token (and verify that it matches the target domain name) and return a successful value. The verification code must be invalidated after this call!<br>4. Instance B, after verifying instance A's request, returns a securely-generated federation key back to instance A. This federation key is a bearer token used to authenticate all requests from instance A to instance B. This key must be unique to instance A!<br>5. Instance A completes the original request with the Authorization header set to Bearer {federation_key}.<br>6. Instance B receives the request, detects the federation key, and checks it against the list of registered instances.<br>7. If the key does not exist or A has been defederated, then a <a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/401" rel="nofollow">403 Forbidden error</a> is returned.<br>8. If the key is expired or revoked, then <a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/401" rel="nofollow">401 Unauthorized error</a> is returned. Upon receiving a 401 error, instance A should start over from step 1 to re-authenticate and complete the request with a new token. This process should not be repeated for recursive failures!<br>9. If the key is approved, then a <a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/200" rel="nofollow">200 OK response</a> or <a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/202" rel="nofollow">202 Accepted response</a> is returned, and A can consider the request as successful.<br><br>Advantages versus HTTP Signatures:<br>- No cryptography requirements.<br>- Simple logic, no edge cases around HTTP query parameters or header order.<br>- Equally effective for all request types.<br>- Keys can be easily revoked or rotated.<br>- Supports authorized fetch and defederation use cases "by default".<br><br>Disadvantages versus HTTP Signatures:<br>- Breaks the actor model - instances are required as a first-class concept. (but really, the actor model is basically dead already. you can't even federate reliably without a WebFinger server, at minimum.)<br>- Requires multi-request "handshake" before communication. (but this is already required in practice, since a signature can't be validated without first requesting the signing actor.)<br>- Out-of-band protocol - communication can't happen over ActivityPub / ActivityStreams because this is a prerequisite to authenticate any request. (but again, we already require WebFinger and some software requires NodeInfo for full support.)<br><br>So, what are your thoughts? Good idea? Bad idea? Did I miss something? Please let me know, I welcome replies here!<br><br><a href="/tags/activitypub/" rel="tag">#ActivityPub</a> <a href="/tags/ap/" rel="tag">#AP</a> <a href="/tags/federation/" rel="tag">#Federation</a></p>
Edited 257d ago
<p>It's sad to see instances shut down without warning, I'm working on a short term and long term plan</p><p>The short term plan: Personal Archive Node (PAN) - The Mini-PDS</p><p>PAN will work with Pixelfed, Loops, Mastodon and other projects, and you can self-host or use a trusted PAN server, giving you peace of mind knowing *most* of your data is easily recoverable + migratable to another server, should you ever need it ✨</p><p>The long term plan: Personal Data Vault (PDV) - DID Layer for ActivityPub</p><p><a href="/tags/soon/" rel="tag">#soon</a> <a href="/tags/ap/" rel="tag">#ap</a></p>