You are reading content from Scuttlebutt
@mix %YaWEWHDWAY6p/g9zIwCJovsd1SUyHpwuGGz3Ug/jtW8=.sha256

Multi-feed identities

My plan so far:

  1. create a mutable "identity" record for minting an identity
    • this record is the reduced state of a collection of messages (a tangle)
  2. create a link between this identity and the feed(s) associated with it
  3. advertise on this identity:
    • a) a public key, which can be used as a unique ID (this is fixed, and can have a private signing key associated with it if we want)
    • b) a DM key (this different to the public key, is a diffie-hellman style key, and can be cycled)

There's a bunch of details to consider about how (2) is implemented, but there's a trickier problem on my mind:

Authorship using multi-feed identities

In #ahau we've recently implemented a permission system for authorship on mutable records. (see https://gitlab.com/ahau/ssb-crut-authors). Internally permission is recorded by recording the feedId+sequence at which a particular person was added/ remove to a list of authors. This means you can easily know whether or not a particular update should be included or not. This mechanism was chosen because it helps with:

  • we don't need to worry about arrival time of messages
  • we aren't relying on asserted position of messages in the tangle (makes it hard for people to hack)

How would this work for a multi-feed identity?

The ID for the author being added would ideally be the MultiFeedId - (3) suggests a public key associated with the record. This would mean that I could personally manage which devices are part of the identity and no work would have to be done changing the listed authors of the record I have authorship on.

BUT... what's the sequence of a multi-feed id (MFI)? Multiple feeds are not order-able - they might be out of sync for a bit. We could consider publishing the sequences of all the feeds - a slice through the feeds of the MFI... but then what do we do if a new feed is added to it?

If we tangle the feeds together - i.e. each message that each member of the MFI publishes now has a tangle field like content.tangles.identity = { root: MFI, previous: [MsgA, MsgB] }, then we could create a partial ordering of all feeds in the tangle. With this we could perhaps define a sloppy-sequence, which is a monotonically increasing number, maybe like a vector clock:

// Multi-feed Identity made up of

CAPS FEED    lowercase feed

       (1) A
           |
       (2) B
          / \
     (3) C   \
        /     \
   (4) D       a (3)
        \     /
     (5) E   /
          \ /
           b (6)
           |
      (7)  F

What are the implications of this?

What are the gotchas if I add an author at MFI-id + MFI-seq (3)

@mix %hg5vwhLd3hozj15eaO47n2ayN1VX7fnXoQuOHlarG3A=.sha256

Here's a collection point for same-as spec : https://github.com/ssbc/sameas-spec

User has not chosen to be hosted publicly
@mix.exe %WNOaAXpTPUNwV+BUysQ9ALUpW5ypdWq1C6eXmz2/ilU=.sha256

further thoughts on using multi-feed identities in authors

if we set aside the problem of being able to add/ remove a MFI, then how do we integrate the the MFI into the authors.

I think you add the id for the MFI, then look up the membership of the MFI (assume this is something similar to the authors field with intervals) then you merge in all those constituent intervals into the state.

nice hand-wavy description, how would you implement it?

  • you'd need a step between when transformations were looked up, and when they were reduce where you hook in and substitute an MFI being added for the current state.
  • this will mess with cache invalidation again...
    • as you can't just look for updates to the record anymore, you have an external contributing record)
    • would have to be able to track which msg keys invalidate which records (which we likely need anyway for redirect messages)
@Anders %5hLbvTjV4PLSBWzK1Bd9a/HxEFkrnWwsxzkWwg7ELOY=.sha256

@mixmix @mix.desktop finally got around to reading this.

For these multi-feed identities how exactly are they different from groups? It seems to me that groups solve the problem of a) shared ID so you can refer to this b) a way to communicate with the group in the form of a key that changes over time as the member list changes over time.

User has not chosen to be hosted publicly
@mikey %ISX7mF/oup6E8S7mgVgQXB3QXDiouBWxaUyo1Z+MKKg=.sha256

thanks for writing this up @mix !

ℹ️

@mix %HYv8gpwWE9VXaRbpQoGvWoY48xtuTa10EQiQbrgiDdU=.sha256

Thanks for the cipherlinks @mikey

@Paul d'Aoust I'm a bit slow catching up on notifications it seems! I thought a lot about how to defend against abuse by time-travellers - i.e. people trying to fake an edit by lying about what they've most recently seen, or their clock. What I've come to so far:

  1. you can't use timestamps
  2. you can bound time-travelling
    • by adding rules like : if there's a message Alice+4 (alice's feed, sequence 4 in her feed), then when alice posts another message in the tangle, (e.g. Alice+5), _this message must be further from the root (than Alice+4)
    • this means a person cannot time-travel to points before where they have already spoken
    • it also has an interesting corollary that means a person cannot legitimately be in two branches of a tangle
                 A  (root)
                / \
               B   C
              /   /
   WARIO+30  D   E  WARIO+65

See in this example Wario who should know about Wario+30 and C and therefore create a merge node, instead tries to play the branches against each other ... but Wario+30 is 2 steps from the root (A) which means than the next post they've made MUST be at 3+ steps from A to be valid. (here we have to count steps as longest possible path).

I've done some code around this but experience so far has shown that it's easy for humans to come up with nice tidy graphs, while in the wild they get messy and harder to reason about. I'm not sure if there are gaps in this thinking

  1. we can lean on human relationships
    • if you have enough problems that you are revoking access to something and a person is getting malicious, you have bigger problems than some tech
    • you might need to completely start a new group/ cycle all keys anyway
    • you can retroactively invalidate messages. e.g. if I say "anything from Paul+254 should be ignored, and concurrently you post Paul+260, then when it comes to merging, argg ... it's midnight I can't do this reasoning now.

:sleeping:

User has not chosen to be hosted publicly
@mix %iqAx8C2avwimx+YtKtKOX5DtdykYi/YYwjLP5wuDRfg=.sha256
Voted Reading this. I really like the general idea. I think it makes sense to thi
User has not chosen to be hosted publicly
@snufkin (yes it's me) %1FwadU+ujCnFCUPN+fGideBCyvbjBM1+7M3oojqRqC4=.sha256
Voted # Multi-feed identities My plan so far: 1. create a mutable "identity" rec
@mix %Cu3HBKhk6Rv5oGnp1M2LRBYbrgkdM1LY/5NAWCkOSlI=.sha256
Voted [@mixmix](@ye+QM09iPcDJD6YvQYjoQc7sLF/IFhmNbEqgdzQo3lQ=.ed25519) no worries
Join Scuttlebutt now