diff --git a/expose.html b/expose.html index d300373..4fec40e 100644 --- a/expose.html +++ b/expose.html @@ -19,7 +19,7 @@

Motivation

With the final standardization of the ActivityPub1 protocol by the W3C, federated social networks seem to have gained traction again with several new social servers implementing it2.

-

But even these current implementations still suffer from a limitation all social networks based on push-federation still have: They can not provide a consistent network-wide view on all public posts including a certain hashtag. Such a search currently only returns posts from the instance's3 local database which have been delivered to the instance anyways due to other subscriptions. This limits the user experience compared to centralized mainstream social networks like Twitter, Tumblr or Facebook.

+

But even these current implementations still suffer from a limitation all social networks based on push-federation still have: They cannot provide a consistent network-wide view on all public posts including a certain hashtag. Such a search currently only returns posts from the instance's3 local database which have been delivered to the instance anyways due to other subscriptions. This limits the user experience compared to centralized mainstream social networks like Twitter, Tumblr or Facebook.

For the Diaspora* network there exists an implementation of a centralized federation relay, where federation servers send all their public posts to and can register to receive all messages containing a certain hashtag. But this centralized approach is against the spirit of federation and decentralization as it forms a single point of failure and potential bottleneck.

Planned Work

The push-federation principle of current federated social networks works on the basis that user identifiers always include their home instance. Thus the server responsible for managing subscription requests and delivering new posts to all subscribers is always known. But there is no such place for all messages containing a certain hashtag, as these can originate from any instance. In federated social networks it is even not necessary for all instances to know each other.

diff --git a/expose.md b/expose.md index 6f91867..0eddbe9 100644 --- a/expose.md +++ b/expose.md @@ -6,7 +6,7 @@ With the final standardization of the ActivityPub^[] protocol by the W3C, federated social networks seem to have gained traction again with several new social servers implementing it^[[Mastodon](https://joinmastodon.org), [Pleroma](https://pleroma.social), [PixelFed](https:pixelfed.org) are examples for general social networks, with several special-interest software like FunkWhale adopting the protocol as well]. -But even these current implementations still suffer from a limitation all social networks based on push-federation still have: They can not provide a consistent network-wide view on all public posts including a certain hashtag. Such a search currently only returns posts from the instance's^[a federation server domain] local database which have been delivered to the instance anyways due to other subscriptions. This limits the user experience compared to centralized mainstream social networks like Twitter, Tumblr or Facebook. +But even these current implementations still suffer from a limitation all social networks based on push-federation still have: They cannot provide a consistent network-wide view on all public posts including a certain hashtag. Such a search currently only returns posts from the instance's^[a federation server domain] local database which have been delivered to the instance anyways due to other subscriptions. This limits the user experience compared to centralized mainstream social networks like Twitter, Tumblr or Facebook. For the Diaspora* network there exists an implementation of a centralized federation relay, where federation servers send all their public posts to and can register to receive all messages containing a certain hashtag. But this centralized approach is against the spirit of federation and decentralization as it forms a single point of failure and potential bottleneck. diff --git a/expose.pdf b/expose.pdf index e77cccf..3ce566f 100644 Binary files a/expose.pdf and b/expose.pdf differ