Federation / Browser Extension

[m90]

Offen is a self hosted service, operators that want to use it for ethically collecting usage data for their sites and services install on a server or a similar service they own. HTTP requests against this service are directed against a subdomain of the operator's primary domain.

This design is good for preserving user's privacy and gives operators fine grained control about the service they are running.

---

A major feature of Offen though is giving users access to their usage data and the ability to understand and manage this data. A landscape of many distinct Offen instances means users have many entry points for particular subsets of their data. This is at best cumbersome, at worst it can cause confusion and uncertainty with users - the exact opposite of why we are building Offen in the first place.

---

This is why we are thinking about ways we can connect the dots for users while still protecting their privacy. This can be done if we federate deployed Offen instances, either on the server side or the client side.

Constraints

The main objective for designing a federated version of Offen needs to be preserving the existing privacy guarantees we can make to users. If we connect instances in any way we need to make sure this does not mean that usage data can be aggregated across instances in any way by operators. This is required to be a privilige solely for users.

Approach: Instance Federation

The server side solution to this task would be federating deployed instances of Offen. This would work in the following way:

1. When deployed, Offen instances publish the hostname(s) they are using to a decentralized network and subscribe to updates by other instances.
2. When a user visits the Auditorium of a particular Offen instance, they can now request a list of other instances known to the federated network.
3. Using the returned list of hostnames, the user can now request any data on these instances associated to them.

Pros

• works out of the box on any device, with no extra burden placed on the user

Cons

• technically challenging to implement
• client side performance will likely be subpar when a high number of nodes needs to be checked

Approach: Browser Extension

When implemented in the client as a browser extension, federation could work in the following way:

1. An interested user installs an Offen browser extension.
2. When visiting a web page that is using Offen, the browser extension keeps track of the instance's hostname and persists it locally.
3. When the user visits an Auditorium of an Offen instance, the browser extension makes sure data from all known hostnames is requested and the aggreate being displayed.

Pros

• Lightweight and technically easy to implement

Cons

• User need to understand why they would need a browser extension and also install it
• Safari support would require developing a dedicated extension as it does not support the web extension standard