From 6a4c7a0a8e72dbbc5732b412fd6ce4868f01a7bb Mon Sep 17 00:00:00 2001 From: Alex Kirk Date: Tue, 4 Oct 2022 03:41:22 +0200 Subject: [PATCH] Ensure subscribing to an rSS feed without self reference will select simplepie --- feed-parsers/class-feed-parser-simplepie.php | 6 + tests/data/blueskyweb-xyz-rss-xml.response | 222 +++++++++++++++++++ tests/test-feed-discovery.php | 9 + 3 files changed, 237 insertions(+) create mode 100644 tests/data/blueskyweb-xyz-rss-xml.response diff --git a/feed-parsers/class-feed-parser-simplepie.php b/feed-parsers/class-feed-parser-simplepie.php index 07c1a8e2..b7dd32bb 100644 --- a/feed-parsers/class-feed-parser-simplepie.php +++ b/feed-parsers/class-feed-parser-simplepie.php @@ -42,6 +42,11 @@ public function feed_support_confidence( $url, $mime_type, $title, $content = nu return 10; } + switch ( $mime_type ) { + case 'application/xml': + return 5; + } + return 0; } @@ -187,6 +192,7 @@ public function discover_available_feeds( $content, $url ) { $discovered_feeds[ $feed_url ] = array( 'type' => $mime_type, 'title' => $feed->get_title(), + 'parser' => 'simplepie', 'rel' => 'self', 'autoselect' => true, ); diff --git a/tests/data/blueskyweb-xyz-rss-xml.response b/tests/data/blueskyweb-xyz-rss-xml.response new file mode 100644 index 00000000..1d7282bb --- /dev/null +++ b/tests/data/blueskyweb-xyz-rss-xml.response @@ -0,0 +1,222 @@ +a:3:{s:7:"headers";a:12:{s:4:"date";s:29:"Tue, 04 Oct 2022 01:31:54 GMT";s:12:"content-type";s:15:"application/xml";s:6:"cf-ray";s:20:"754a291b68e37809-VIE";s:13:"cache-control";s:17:"public, max-age=0";s:4:"etag";s:20:"W/"ab0a-18342f63800"";s:13:"last-modified";s:29:"Thu, 15 Sep 2022 21:02:56 GMT";s:4:"vary";s:15:"Accept-Encoding";s:15:"cf-cache-status";s:7:"DYNAMIC";s:29:"x-envoy-upstream-service-time";s:1:"7";s:6:"server";s:10:"cloudflare";s:16:"content-encoding";s:2:"br";s:7:"alt-svc";s:43:"h3=":443"; ma=86400, h3-29=":443"; ma=86400";}s:4:"body";s:43786:" + + + Bluesky + https://blueskyweb.xyz + The latest from the Bluesky project. + Thu, 15 Sep 2022 21:02:56 GMT + https://validator.w3.org/feed/docs/rss2.html + https://github.com/jpmonette/feed + en + Bluesky 2022 + + <![CDATA[Working In Public]]> + https://blueskyweb.xyz/blog/5-4-2022-working-in-public + https://blueskyweb.xyz/blog/5-4-2022-working-in-public + Wed, 04 May 2022 00:00:00 GMT + + It’s been four months since the Bluesky company got funding and started hiring a team. Now that we have a few people on board, we’re starting to work in public.

+

Today we’re releasing ADX, the “Authenticated Data Experiment”. Our company's name, “bluesky,” describes the open-ended nature of this project, and the freedom we were given to start from first principles. As we get more concrete, we’ll give more specific names to what we’re building, starting with ADX.

+

The Process

+

What does “working in public” mean? It’s a process of being transparent and available to the public, and takes place on a spectrum. On one extreme, I could be livestreaming the writing of this post, taking feedback from the audience as I go. Our teammate Paul actually did this for a prior decentralized social network app he built – you can check out the livestream history at each git commit here. On the other extreme, we could try to fully develop everything before releasing it to the world. At Bluesky, we’re going to take a middle path of releasing work before it’s complete, but also giving ourselves time to workshop new directions at early stages. Going forward, we’ll be experimenting with some different ways to engage publicly to figure out how to strike that balance.

+

The Writing: Words & Code

+

This week we’re releasing code for an experimental personal data server and a command-line client. We’re also sharing a high-level overview of the network architecture grounded in a technical description of what the data repository is and how it works. Feel free to play around, but don’t try to build your next big social app on this yet. Things are missing, and things are going to change. We’ve been writing code to validate ideas and discover edge cases as a part of the research process, as opposed to writing code to produce a finished product.

+

Along with the code, our architecture overview should give you some insight into the ideas we are pursuing. The analogy for this demo is “git, for your social posts.” And if this is git, it only begins to indicate how GitHub or GitLab works. There’s a lot of other parts to the system that will shape the user experience, so you’ll probably have some questions. We’ll try to engage with incoming questions and feedback over the coming weeks.

+

As we release the first experiment, we anticipate a common question will be “why didn’t you use X?” In places where it made sense, we used existing building blocks that were flexible, modular, and had good tooling. More opinionated stacks might contain good ideas, but we needed the freedom to optimize for our own requirements without designing around existing architectures. There’s always the possibility of integration or interop in the future.

+

We’re in R&D mode at the moment, experimenting with pieces that point in the right direction. We don’t have a finished product or a fully-specified protocol, but we’re putting together components that we believe will enable a social media ecosystem with a healthier balance of power. This isn’t a complete picture yet, and doesn’t lay out how we’ll be getting from here to there. These are the first steps — there’s still a lot more to do.

+

If you have questions about the architecture or code, drop in to our Matrix dev channel to talk to the developers. Let’s move from platforms to protocols!

]]> + hello@blueskyweb.xyz (Bluesky) + + + <![CDATA[A Self-Authenticating Social Protocol]]> + https://blueskyweb.xyz/blog/3-6-2022-a-self-authenticating-social-protocol + https://blueskyweb.xyz/blog/3-6-2022-a-self-authenticating-social-protocol + Wed, 06 Apr 2022 00:00:00 GMT + + Bluesky’s mission is to drive the evolution from platforms to protocols. The tools for public conversation should exist outside of private companies as common infrastructure, like the Internet itself. An open and durable decentralized protocol for public conversations can allow users a choice in their experience, creators control over their relationships with their audience, and developers freedom to innovate without permission from a platform.

+

We started with a research-intensive process to learn what can be applied from existing decentralized protocols. This research began with the ecosystem review and has continued while the Bluesky team was forming. We will be publishing our preliminary work and research this month, starting with this high level introduction. There are many projects that have created protocols for decentralizing discourse, including ActivityPub and SSB for social, Matrix and IRC for chat, and RSS for blogging. While each of these are successful in their own right, none of them fully met the goals we had for a network that enables global long-term public conversations at scale.

+

Some of the most important objectives we have been evaluating are portability, scale, and trust. Portability allows people to keep their social life intact even if they switch providers. Scale allows people to participate in global discourse. And trust is created by giving people insight into what services are doing with their data and how information is being promoted into or removed from their feed. To dive a bit deeper into each topic:

+

Portability

+

Portability is the ability to move between services without losing everything, like how we can switch mobile carriers without losing our phone numbers. User choice requires portability for identity, data, payments, and any other service. When people can switch providers without losing their identity or social graph, then social media can work as a competitive open market again.

+

With email, if you change your provider then your email address has to change too. This is a common problem for federated social protocols, including ActivityPub and Matrix. If your ActivityPub server shuts down, you lose your identity and relationships tied to your account on that server, just like you would if any other social platform shut down. Since ActivityPub servers are much smaller than the existing platforms, and often run by volunteers, this scenario is not unlikely and has happened before. We want users to have an easy path to switching servers, even without the server’s help.

+

Scale

+

Social networking platforms bring hundreds of millions of people together in a global conversation. Some people prefer smaller communities, and ActivityPub and SSB are great for those tight-knit groups, but with Bluesky we want to give users the option to participate in global conversations the way they do on large social networking platforms.

+

Operating at scale requires engineering for scale. Early on, Twitter’s site crashed so often that the “fail whale” became a meme. They’ve since solved these problems, but existing decentralized networks that try to replicate the functionality of big platforms have not. When you search a trending hashtag on social media and find posts from around the world or see a viral post that has 125k likes, this is the service providing you with a global view across the network while hiding the complexity under the hood. By decentralizing aspects of social platforms, we’re adding cross-organizational networking that re-exposes the complexity. A protocol for conversations at scale needs to be developed around these challenges at every step.

+

Decentralization adds new functionality in other domains, but when it comes to scale, we’re aiming to replicate the global experience that social networking platforms currently offer. Existing decentralized social protocols default to local conversations because it’s a natural fit for a decentralized architecture, but our goal is to make global conversations possible while preserving the freedoms users gain from interacting through an open protocol.

+

Trust

+

Decentralized networks are complex. Providers need to manage spam and abuse without inadvertently creating biases which lose the trust of their users. This is even more important for the algorithms that drive our feeds. Social media has the power to shape cultural discourse and needs to exist within a system of checks and balances. Like scale and portability, we aim to build around trust from the start by exposing what’s going on under the hood and allowing users to adjust their experience.

+

Starting as centralized platforms, social networks can take steps to open up APIs and provide choices to users, and this can be a path towards restoring trust in the current service. The premise of Bluesky, however, is to work towards a transparent and verifiable system from the bottom up by building a network that is open by default. We’ll do this by giving users ways to audit the performance of services and the ability to switch if they are dissatisfied.

+
+

The conceptual framework we've adopted for meeting these objectives is the "self-authenticating protocol." In law, a “self-authenticating” document requires no extrinsic evidence of authenticity. In computer science, an “authenticated data structure” can have its operations independently verifiable. When resources in a network can attest to their own authenticity, then that data is inherently live – that is, canonical and transactable – no matter where it is located. This is a departure from the connection-centric model of the Web, where information is host-certified and therefore becomes dead when it is no longer hosted by its original service. Self-authenticating data moves authority to the user and therefore preserves the liveness of data across every hosting service.

+

The three components that enable self-authentication are cryptographic identifiers, content-addressed data, and verifiable computation. The first two are familiar concepts in distributed systems, and the third is an emerging area of research that is not yet widely applied, but that we think will have large ramifications.

+

Cryptographic identifiers associate users with public keys. Self-sovereign identity is based on having cryptographic identifiers for users. Control of an account is proved by a cryptographic signature from a user, rather than an entry in a database keeping track of logins.

+

Content-addressed data means content is referenced by its cryptographic hash — the unique digital “fingerprint” of a piece of data. Using public keys and content-addresses, we can sign content by the user's key to prove they created it. Authenticated data enables trust to reside in the data itself, not in where you found it, allowing apps to move away from client-server architectures. This creates “user-generated authority”.

+

Verifiable computation uses cryptographic proofs to allow observers to verify that a computation was performed correctly without having to run it themselves. This can be used to preserve privacy by concealing inputs, as in a zero-knowledge proof, or to compress state that would otherwise have to be kept around for verification. The full potential of these cryptographic primitives is still being explored. Cutting edge research is currently being applied to scaling blockchains, but we are also investigating novel applications in distributed social networks.

+
+

Now that we've explained self-authenticating protocols, let's look at how the components help us achieve our goals.

+

Portability is directly satisfied by self-authenticating protocols. Users who want to switch providers can transfer their dataset at their convenience, including to their own infrastructure. The UX for how to handle key management and username association in a system with cryptographic identifiers has come a long way in recent years, and we plan to build on emerging standards and best practices. Our philosophy is to give users a choice: between self-sovereign solutions where they have more control but also take on more risk, and custodial services where they gain convenience but give up some control.

+

Self-authenticating data provides a scalability advantage by enabling store-and-forward caches. Aggregators in a self-authenticating network can host data on behalf of smaller providers without reducing trust in the data's authenticity. With verifiable computation, these aggregators will even be able to produce computed views – metrics, follow graphs, search indexes, and more – while still preserving the trustworthiness of the data. This topological flexibility is key for creating global views of activity from many different origins.

+

Finally, self-authenticating data provides more mechanisms that can be used to establish trust. Self-authenticated data can retain metadata, like who published something and whether it was changed. Reputation and trust-graphs can be constructed on top of users, content, and services. The transparency provided by verifiable computation provides a new tool for establishing trust by showing precisely how the results were produced. We believe verifiable computation will present huge opportunities for sharing indexes and social algorithms without sacrificing trust, but the cryptographic primitives in this field are still being refined and will require active research before they work their way into any products.

+
+

In this post, we’ve started to lay out the high level objectives we’ve set and how we plan to meet them. In the coming weeks, we’ll be publishing more of the research we’ve done since the ecosystem review and open sourcing preliminary code. We’ve started writing code to validate ideas and iterate on something concrete, but everything is still fully experimental. You can expect a command line client to play with, but don’t expect to build your next big app on it yet, as anything can change at this stage.

+

We’re not describing what we’re building as a federated or p2p network, or as a blockchain network, because it doesn’t fall neatly in any of these categories. It could be described as a hybrid federated network with p2p characteristics, but it’s more descriptive to focus on the capabilities – self-authenticating identities and data – than on network topology. Our team has previously built leading decentralized web protocols and blockchain networks, and is working on synthesizing the best of what we’ve seen into something new. For some aspects, we’ll be able to use pieces that already exist, and for others, we’ll have to come up with solutions of our own. Stay tuned for updates, we’ll share more soon.

]]> + hello@blueskyweb.xyz (Bluesky) + + + <![CDATA[The Initial Bluesky Team]]> + https://blueskyweb.xyz/blog/2-31-2022-initial-bluesky-team + https://blueskyweb.xyz/blog/2-31-2022-initial-bluesky-team + Thu, 31 Mar 2022 00:00:00 GMT + + As the Bluesky lead, my first priority has been to build a great team. Today, I’m excited to announce our first hires and technical advisors.

+

The initial members of our team are:

+
    +
  • Daniel Holmgren, a protocol engineer with previous experience developing on IPFS at Fission. Daniel previously co-founded a Consensys-backed startup working on p2p data transfer for scientific data sets.
    • +
  • Paul Frazee, a protocol engineer and full-stack web developer. Paul previously built Patchwork, the first application using the SSB distributed social protocol, and Beaker Browser, the first web browser for the Hypercore distributed web protocol.
    • +
  • Aaron Goldman, a security engineer who was most recently at Twitter. He previously worked on trust & safety at Google, and has been interested in distributed systems going back to a thesis he wrote on content-addressed filesystems in 2014.
    • +
+

Technical advisors to the team include:

+ +

With more people on board, we’re now able to start open sourcing our protocol development process. Our plan was to start working in public as soon as we had enough people to answer questions, engage with the community, and participate in public conversations. Watch for more to come in the following weeks.

+

—

+

I’m also still hiring, and would love to bring on another protocol engineer who thinks in code and likes prototyping. We now have deep and varied technical expertise across the organization, and are looking for a prolific developer to support and accelerate the work of experienced systems architects. Learn more and apply here: blueskyweb.org/join/protocol-engineer.

+

To support the early stages of our engineering-focused org, we’re looking for the first business operator to help manage processes internally and be a voice for Bluesky externally. If you’re excited about doing whatever it takes to get an early stage organization off the ground and have past experience in operations, strategy, and/or partnerships, then we hope to hear from you. The ability to understand and explain technical topics is a must, and a technical background is a bonus, though not a requirement. Learn more and apply here: blueskyweb.org/join/business-operations.

]]> + hello@blueskyweb.xyz (Bluesky) + + + <![CDATA[How it Started]]> + https://blueskyweb.xyz/blog/2-28-2022-how-it-started + https://blueskyweb.xyz/blog/2-28-2022-how-it-started + Mon, 28 Feb 2022 00:00:00 GMT + + TLDR: Bluesky was announced in 2019 but the legal entity itself was only recently set up. In the meantime, the bluesky community took shape and has taken on a life of its own. There now exists two separate organizations, the bluesky community and Bluesky PBLLC. We’ve been using lowercase “bluesky” to refer to the original open-ended project, and uppercase “Bluesky” to refer to the company with that namesake. Below, Jay wrote a post called “Three Phases” on the origins of bluesky, and Golda wrote “Bluesky-community” to describe what’s been going on in the community.

+

Three phases

+

by Jay Graber

+

Bluesky began with an idea, developed into a community, and solidified into a company, in three stages. The formation of Bluesky, PBLLC at the end of 2021 marked the beginning of the most recent stage, where we now have funding and an organization to pursue our mission.

+

Phase 1: The idea

+

The bluesky project began with a tweet by Jack Dorsey announcing Twitter’s intentions to fund the development of an open protocol for decentralized social media. Many people DM’ed the new bluesky Twitter account to learn more – including Golda and myself. Twitter brought about a dozen of us together in a Matrix chatroom, and that was the beginning of the initial discussions of what bluesky should be.

+

how-it-started-chatroom.png

+
The first bluesky community chatroom
+

In an initial Q&A in that room, Jack wrote “The biggest and long term goal is to build a durable and open protocol for public conversation. That it not be owned by any one organization but contributed by as many as possible. And that it is born and evolved on the internet with the same principles.” This resonated with us. Twitter’s support for this was exciting, because of all the people who already use it as a platform for public conversation, but we also knew this needed to be independent from Twitter to succeed.

+

Twitter’s creation of that Matrix room was partly an experiment in self-organization, to see if the direction and leadership of bluesky would emerge from that community. Many people were generous with their time in contributing insight to the discussions, including Jeremie Miller (inventor of XMPP who is now on the Bluesky board), Matthew Hodgson (technical co-founder of Matrix), Ian Preston (co-founder of Peergos), and rabble (early Twitter engineer and co-founder of Planetary). However, around the same time the bluesky community chatroom was created, COVID-19 was beginning to take the world by storm. 2020 threw organizations and personal lives into chaos. Midway through the year, Golda proposed we open up the community to more builders, and I proposed writing an ecosystem overview of existing decentralized social networks.

+

how-it-started-overview.png

+
A diagram from the ecosystem overview
+

We created a bigger version of the bluesky chatroom that grew to around 60 people, and I started writing an overview of all the projects in the space. The ultimate shape of the bluesky project remained undetermined, but the bluesky community was starting to connect people to talk across projects and building up a collective knowledge base in the form of the ecosystem review.

+

Phase 2: The community

+

Sometime in 2020, Twitter put out a request for proposals to the community group. Several of us wrote technical proposals on how we thought a novel decentralized social protocol could work, either building on existing protocols or starting from scratch. In 2021, Twitter interviewed people for the role of bluesky lead, and ended up nominating me. I say nominating rather than hiring, because rather than starting to work for Twitter, I started spinning up an independent organization that would receive funding to make bluesky a reality.

+

I knew there was going to be a lot of press when I was publicly announced as bluesky lead, but I didn’t have anywhere to direct people yet, so I asked Golda to help with opening up the bluesky community to anyone interested in joining. Her side project was a social events startup that could help cover the costs of hosting and moderating a public community until the Bluesky company got set up. On the day of the announcement, we launched a blueskyweb.org site that I put together, and a bluesky Discord and blueskycommunity.net site that Golda put together. We discussed how to best channel the enthusiasm of newcomers in a productive direction, and decided to direct energy into core topics and existing projects. This ended up creating a lively forum for debate and discussion, becoming a unifier for once disparate conversations.

+

Phase 3: The company

+

In the last few weeks of 2021, we got the Bluesky PBLLC established and funded. We decided to keep the community as a separate organization, funded through grants from the Bluesky company, so it can function as an inclusive forum while the company pursues more focused research and development. At the Bluesky company we want to start being more public, having more conversations with companies besides Twitter, and engaging with other protocols, but first we need to finish hiring and articulate the technical vision for our proposed direction. In the meantime, the community continues to be a place for discussion and debate, where we participate but do not drive conversations.

+
+

Bluesky-community

+

by Golda Velez

+

When I saw the announcement about bluesky I felt this effort was tremendously important, but also could be really hard to get right. My perspective on it was shaped by work in risk, where we have organized attackers, and human rights work, where we can see the effect on people of both authoritarian control of networks and the real dangers of disinformation tactics. If Bluesky can enable open public conversation that is resistant to manipulation, yet in which players can innovate and evolve rapidly, then we really have something.

+

I had a related effort I was working on, WhatsCookin, which relates to building communities and also decentralizing control. So when Jay asked if I could help open up the bluesky community, we leveraged WhatsCookin where we have this global team of developers and community-oriented people who could help plan events and actually help dogfood the tech in the process. For example, right at the beginning we bridged the Discord to a set of Matrix rooms. And we got to see what the limitations are of bridges in terms of threads, reactions, and stability. The great thing is that people in the dweb ecosystem are enthusiastic about participating, so we had core people like Thib Martin in the Matrix community helping fix the bridges and ensure they were working.

+

The most visible effort has been the Community Voices audio series that we produce in collaboration with the Bluesky organization. The series, conducted on Twitter Spaces, is led by Robert Schwentker, who organized the nascent Twitter developer community a decade ago and since has been involved with web3 efforts globally. The topic for each episode delves into critical components and challenges of the decentralized web ranging from Identity to Storage, Reputation to User Experience. We invite experts and leaders in the space to discuss the technical, social, and historical nuances, and include "skeptic" voices from more traditional and corporate backgrounds.

+

how-it-started-communityvoices.png

+
One of the many community voices sessions on Twitter
+

The goal of the bluesky community, as distinct from the Bluesky organization, is to foster collaboration in the decentralized web ecosystem. It's a very organic approach. We have an open perspective. We also share the Bluesky objective of driving adoption of decentralized tech, so we try to give a platform to different players, hold educational talks and forums, and do small projects to give developers a chance to work together and learn new tech. The community space, which is this bridged discord/matrix forum, has groups from the fediverse, matrix, ssb, gun, ceramic, solid, peergos, holochain, metamask and more. We believe that “work talks” and anyone can lead an effort if people are interested in following. So in addition to the organized forums we put on, anyone can schedule a "pop-up" about subjects related to the dweb ecosystem.

+

We recommend newcomers start by reading the Ecosystem Review Jay wrote as a guide to the space, then actually meet the people working on them and dive in. In a lot of ways it feels like the early days of the Internet, where people shared whitepapers of algorithms and prototypes of new browsers person to person, before they took off and shaped the web. Non-developers are welcome as well, because there is plenty to do around communicating and organizing. So whoever you might be, you're welcome to join us — enter through blueskycommunity.net.

]]> + hello@blueskyweb.xyz (Bluesky) + + + <![CDATA[Announcing Bluesky PBLLC]]> + https://blueskyweb.xyz/blog/2-7-2022-overview + https://blueskyweb.xyz/blog/2-7-2022-overview + Mon, 07 Feb 2022 00:00:00 GMT + + In 2019, Twitter announced bluesky, a project it would fund to create an open and decentralized standard for social media. Since then, the bluesky community has been working together to better understand the existing decentralized web ecosystem, and outline the core tenets of what an open protocol for social media should include and the technologies on which it should be built.

+

Today, we are excited to announce the formation of the Bluesky PBLLC, a Public Benefit LLC that will implement that vision as an independent organization. Our mission is to develop and drive large-scale adoption of technologies for open and decentralized public conversation. We were formed in late 2021 with the initial funding provided by Twitter. Our board members include Jack Dorsey, a founder of Twitter, Jeremie Miller, the inventor of Jabber/XMPP, and Jay Graber, CEO of the Bluesky company.

+

We envision an open social media ecosystem where developers have more opportunity to build and innovate, and users have more choice and control over which services they use and their experience on social media as a whole. The development and adoption of decentralized protocols is a path we see towards establishing a strong technical foundation for permissionless innovation and user choice. Decentralization is a structural change that in itself is insufficient for creating a healthy social media ecosystem. However, by creating an environment where developers can freely build, communities can self-govern, and users can easily switch services, decentralization can catalyze the innovation necessary to improve the public conversation.

+

The many existing decentralized social networks that currently make up the ecosystem can be categorized into federated and p2p architectures. Our approach will be to combine the best of both worlds by integrating the portability of self-certifying protocols with the user-friendliness of delegated hosting, so users don’t have to run their own infrastructure and developers can build performant apps. Moderation is an important part of any online social forum, which is why we will proactively build tooling for reputation and moderation systems that are transparent, opt-in, and multi-layered, as well as create frameworks for others to build such tooling. We’re building on existing protocols and technologies but are not committed to any stack in its entirety. We see use cases for blockchains, but Bluesky is not a blockchain, and we believe the adoption of social web protocols should be independent of any blockchain.

+

Our current focus is on building and releasing a prototype that illustrates our approach. Stay tuned for news about our new team members soon. To participate in the community and follow our progress, join the bluesky community, or follow our Twitter account for updates.

]]> + hello@blueskyweb.xyz (Bluesky) + + + <![CDATA[Satellite - A bluesky contest]]> + https://blueskyweb.xyz/blog/satellite + https://blueskyweb.xyz/blog/satellite + Mon, 13 Dec 2021 00:00:00 GMT + + Our digital identities are like satellites we launch into cyberspace. +You may link one to another here and there, but how would you link all of them, +systematically, in a way that proves to others they belong to you?

+

Our Satellite contest asked for submissions that demonstrated how to link accounts and content. +$300 in BTC was awarded to the top three, and there was an additional participation prize in the form of a NFT given to others.

+

Here was the original prompt: Choose at least 3 of the following. Link them in a way that anyone can verify you are the author/owner of all. +Explain how you did it, and what properties you were designing for.

+
    +
  • A Twitter account
    • +
  • A Reddit account
    • +
  • A website... or two
    • +
  • A Matrix account
    • +
  • A Mastodon account
    • +
  • An SSB account
    • +
  • A PGP key
    • +
  • A piece of content on IPFS
    • +
  • A cryptocurrency address
    • +
  • Another decentralized social network
    • +
  • Another service/platform of your choosing
    • +
+

We scored submissions on a rubric of: thoroughness, robustness, +originality, decentralization. The winners were:

+

Satellite Top Three

+ + + + + + + + + + + + + + + + + + + + + + + + + +
RankPseudonymName
1.DevignyWes Chow
2.woodpigeonRichard Newman
3.peergosPeergos
+

Devigny, aka Wes Chow

+

https://github.com/wesc/devigny-poc

+

Summary: zk commitments published on different accounts can be published in a proof book to link them together, or left until the prover chooses to reveal them. We like how this allows the association between accounts to be kept private until the prover chooses to reveal them. The solution is well-explained, with a theory section going into how the cryptography works. The tool is implemented with a command-line interface and could be extended to many different types of accounts. It is decentralized, because there is no central site where proofs have to be aggregated or linked to - a proof book can be displayed in any way. And it is certainly an original application of cryptographic primitives.

+

Woodpigeon, aka Richard Newman

+

https://github.com/rnewman/scua

+

Summary: A browser extension to track claims of account ownership through association with ION DIDs. Rather than presenting a theoretical explanation of how to use DIDs, which is where many ideas for their usage ends, this picks an implementation and sees it through. I liked the attention to user experience, the practical implementation of an existing decentralized id standard, and the thorough reasoning and explanation. It doesn’t present a novel attestation protocol, but it pulls pieces together in a cohesive and unique way.

+

Peergos

+

*long peergos link, because object capabilities*

+

Summary: Peergos took the prompt as inspiration to integrate an identity linking protocol into their existing system. It builds upon prior work put into Peergos for a decentralized and encrypted way of controlling access to files with user keys and, by doing so, allows proofs to be both public and private. This was a fairly robust solution that deserved to be highlighted for its robustness, decentralization, and additional feature of optional privacy.

+

Honorable Mentions:

+

Lucas Meier, Andy Raddatz, IndieWeb solutions, Gershon Ballas

+

Lucas Meier

+

https://cronokirby.com/posts/2021/09/bluesky_satelllite/

+

Lukas submitted a solution on the first day of the contest that is simple but captures the gist of a cryptographic attestation-based linking method. I appreciated how quickly he put this together.

+

Stretch, aka Andy Raddatz

+

https://gist.github.com/andyraddatz/6f90c1c567d072d33ec4c530daf528d6

+

Stretch’s solution had an interesting application of BLS signatures. A BLS keypair is published with each site, so an association between all sites is proven by aggregating the public keys and checking the aggregate signature. +There is no single keypair that controls all accounts.

+

Indieweb solutions: Ryan Barrett, Barack Sokullu

+

https://snarfed.org/bluesky-satellite-contest-entry

+

sokullu-satellite.pdf

+

Several people submitted well-written IndieWeb solutions. They weren't as original and decentralized as the winning submissions that had implementations that did not require platform-level support, but they described a simple and straightforward way to link identities across the web. +Ryan Barrett has a good writeup of how the IndieWeb syntax of “rel-me” bidirectional links can be used to link websites. Barack Sokullu wrote an explanation as well as designed mockups of how “rel-me” links could be taken a step further by linking to DIDs, which would provide keypairs that could be used to sign content.

+

ggballas, aka Gershon Ballas

+

https://github.com/ggballas/satlink

+

Gershon implemented a smart contract in Solidity to prove ownership of different accounts/content. This is one of the few that pointed out how to show "ownership" of an IPFS hash, through an NFT held by an address.

]]> + hello@blueskyweb.xyz (Bluesky) + + +";s:8:"response";a:1:{s:4:"code";i:200;}} \ No newline at end of file diff --git a/tests/test-feed-discovery.php b/tests/test-feed-discovery.php index 0e025f9d..56310036 100644 --- a/tests/test-feed-discovery.php +++ b/tests/test-feed-discovery.php @@ -84,4 +84,13 @@ public function test_chriswiegman() { $this->assertArrayHasKey( 'autoselect', $feeds['https://chriswiegman.com/feed/'] ); $this->assertTrue( $feeds['https://chriswiegman.com/feed/']['autoselect'] ); } + + public function test_blueskyweb() { + $friends = Friends::get_instance(); + $feeds = $friends->feed->discover_available_feeds( 'https://blueskyweb.xyz/rss.xml' ); + var_dump( $feeds ); + $this->assertArrayHasKey( 'https://blueskyweb.xyz/rss.xml', $feeds ); + $this->assertArrayHasKey( 'autoselect', $feeds['https://blueskyweb.xyz/rss.xml'] ); + $this->assertTrue( $feeds['https://blueskyweb.xyz/rss.xml']['autoselect'] ); + } }