Skip to content

Design notes

Jump to bottom Edit New page
Maria Kozinska edited this page Feb 21, 2022 · 1 revision

Problem: current platforms are centralized

=> uniformization and power imbalance

(social perspective)

1. Uniformization

TBD

2. Too much power in boards

Related problems: users are locked to the platforms - individuals and communities as a whole are trapped, deleted accounts, censorship, "competitive advantage" of a platform based on user base not features, people in position of power are tempted to benefit from the communities: paywalls, sold data, advertisements, addictive methods to catch attention, ...

Related future vision: fair 'competition' between platforms based on features not users base, evolution of the whole hospex ecosystem, platforms built to serve a specific group of people rather then trying to fulfill needs of all, more people can find a place for themselves in the broad hospex landscape

(technical perspective)

But: for people in their offline life, identity comes from belonging somewhere (could be an instance) and not elsewhere

  • but-but: non-permanent in time through life
  • but-but: many (more than one) identities at a time
  • aliases? like nicknames

Some questions:

  • Do servers (communities) interact with each other (federated, S2S part of AP) or not at all (fully decentralized P2P; SSB, nostr)?
    • MK: hosting offers: location - yes, description - no
  • Who owns identity? a user or a platform?
    • user@host
    • uuids/guids/ulids (+ encription, based on priv/public keys)
    • (content hashing)
  • What belongs to the community and what to the individual?
    • to consider: online identity (address), profile (description), hosting offer(s) (location+description) - one per user (for all communities) or one per user per community?
    • when stationary, one hosting offer per user (for all communities) or per community? - per community => platform own hosting offers
    • when traveling, one hosting request per user or per community? - per user, broadcasted to chosen communities => users owns hosting requests
  • Who owns data?
    • user - local on a client side (SSB, nostr) or remote (Solid)
    • community - stored on a platform/server/common infrastructure
    • whole network - replicated between platforms
      • ex. geographical location
    • user's network - replicated between user's connections/communities members
      • ex. reputation?

Solutions

In general they come down to:

  • freedom to move (profile portability) + discoverability of other communities (visibility of existance of offers/requests accross platforms)
  • freedom to interact between platforms/communities

Protocols/architectures to review/understand: Check Comparison of decentralized protocols

Profile portability

(complete with all users connections, history, reputation, etc)

Github issue: Easy account migration between instances (nomadic identity)

  • portable identity - identity based on globally unique ids or public/private key (like in ScuttleButt, zot from hubzilla) vs id owned by a platform (as in matrix @username:host where user is locked to the host)

    • ? ideate? pros and cons of both?
    • how to find users then? some address resolution system would be needed...
    • who issues ids / uuid / public-private keys? some central authority?...
    • how communities would work then? just a list (index) of members?
    • can we implement it gradually? start with user@host and then abstract to globally unique ids?

  • common among platforms format + data owned by a user

    • data storage decoupled from app layer, stored and managed externally, ex. Solid, datashards, freenode, ...
    • client side encryption - David described the ideas here Think lastpass or Metamask where a server stores an encrypted file with your PII which is only decrypted client side and all cryptographic ops involving a private key happen in browser or on a trusted hardware module.

  • easy self-hosting - comes down to owning your identity and data, if you choose to

    • problems: you want to self-host as an after-thought when you are already banned/censored/removed from the community
    • can be made easy, still not for everyone

  • linked identities across servers

Note: ScuttleButt inability to genuinely delete anything will create an existential crisis if it were to go mainstream - mastodon toot

... next time, if it worked well :) ...

Communication between platforms

How to discover hosting offers/requests on other platforms in the network?

  • Github: issue about Federated search and Callum's questions under some other issue

  • Queries forwarding or users (hosting offers) forwarding?

  • How big namespace do we need?

    • current stats: 70k on TR, 160k BW, maybe 130K WS, 170k HaS..., 12m on CS
    • Let's assume 1M users (note: not everyone is a host!)
    • uuids - globally unique
      • 2^20 > 1M, smallest that is enough
      • 2^24 > 16M, 3bytes allows to address over 12 millons of users, with 0.75 load factor for hasing function to avoid collitions ;)
      • 2^32 > 4G, 4bytes gives namespace for over 4 mlds of users, enough namespace for half of the humanity, regardless of age, to offer a stay at their home
      • zot uses 2^256 namespace size, that would need 32bytes of storage per user
    • user@host
      • max host length: 256 chars => 256 bytes (without user part)
      • let's assume on evarage 32chars => 32bytes

  • How much space would it take to store all hosts?

    • uuids:
      • each user on a map: (uuid, longitude, lattitude) -> 4 + 1 + 1 byte = 6 bytes
      • 1M * 6 bytes -> 6Mb to store all users in the network
        • it's ok even for a single user instance
    • user@host
      • each user on a map: 32 + 1 + 1 byte = 34 bytes
      • 1M * 34b -> 32Mb for all users
        • still ok

  • ActivityPub S2S

  • Request flow diagram

Request flow for:

  1. publishing a hosting offer
  2. searching for a host and requesting a stay
request flow

Boundaries between platforms

Who chooses who to interact with, and how much?

  • see notes from our weekly meeting, leftovers from 21.10.04

  • levels of 'trust'

  • problem: spam or some unacceptable content

    • harmful user on an instance
      • an admin should block them
      • bonfire develops zeppa, an extention to classify content for disinformation, based on data from communities preferrences (ML)
    • harmful instance which accepts that user

  • ...

Messaging across platform boundaries

  • use external messaging service, like phone number
  • ActivityPub C2S, integrates with Mastodon
  • matrix?
  • p2p
Add a custom footer
Add a custom sidebar
Clone this wiki locally