You are reading content from Scuttlebutt
@neftaly

I sent Dom the following last week, but he refused to answer unless I posted to SSB!

I've been having a play around with SSB, and was curious why messages and blobs have a distinct identifier? Couldn't you just infer what they are by context?
Also, why don't you use a protocol prefix for SSB identifiers? For example (based off https://tools.ietf.org/html/rfc6920):
ssb://sha-256;UuDYPy7ae9ese2I7opJxiWVPQcgtZEF4amYqb9qQLiw?type=message
cause then you could do clickable links etc

I would also like to know more about how sequence works -

  • Does each new post in a message chain add 1 to the last-seen sequence number?
  • What about messages that arrive late (and have a low seq number)?
  • What about messages that falsely claim to be from the future (sequence + 100)?
  • How is it different to simply inferring the sequence number from the previous prop?
@neftaly

Also, I am concerned about having hash types in IDs, as there is a potential implication that (ignoring the fact that only SHA256 & ED25519 is currently supported) a SHA-3 ID for a bit of content is just an alias for a SHA-256 ID. Is this a thing?

User has chosen not to be hosted publicly
@Dominic

Does each new post in a message chain add 1 to the last-seen sequence number?

no, it's sequence number per feed, so it's also the length of the current list of your posts.

If a message is not msg.sequence === latestSequence(feed_id) + 1 will be rejected as invalid.

It uses a number, because when you replicate each peer sends <id>:<sequence>. and one peer with the higher sequence for that id sends the messages the other is missing. This idea comes from the original amazon scuttlebutt paper. flowgossip.pdf

@Dominic

Re:sigils % & @ one reason was to have these as a user interface. The user types @ and that triggers autocomplete. Users are already familiar with this idea from twitter, etc. Context isn't quite enough, you can paste either types into a markdown post, so it help the UI to know which type it is. (blobs, messages, and feeds) are all stored different places.

We could use a protocol prefix, or on the links? as they are rendered? This would be an easy way to integrate with other p2p apps.

@Dominic

Oh, we definitely need the hash extention. If we didn't have that, you'd just have to hash every object with every hash algorithm. If all the algorithms are secure, this would be secure, but what if one becomes insecure? Maybe you'd be able to generate an object that has the same sha2 hash as a given blake2 hash? (they are the same length)

But since we have the extention, we know that we mean specifically the blake or the sha hash.

You could use two different algorithms to refer to one object, and you'd need a lookup table to map the hashes, or hash everything twice.

Messages also have a hash property which indicates the primary hash algorithm the idea is to upgrade a hash, refer to that message's primary hash + new hash. maybe %<hash_sha256(msg)>.sha256/<hash_blake2(msg)>.blake2

Which effectively says "of all the messages with this sha256 hash, I mean the one that also has this blake2 hash" so if sha256 get weak, you can still refer to that object securely from new messages.

That is basically the plan, but not actually implemented yet.

@neftaly

Regarding the hash extension, couldn't you then make a post with a broken hash algo key, that intentionally collides with the key of a legit message originally made with a non-broken key algo, and overwrites the index reference? Though I guess some kind of fix would be to ignore new messages containing any sort of blacklisted hashe (even just mentioning one in a comment body etc) after deprecation.

@neftaly

Shouldn't the sigils only be a user-interface hint? So if you type %whatever, the UI takes that as a hint to show an autocorrect, but it actually encodes it as a special symbol/token of sort (such as a URI). That'd make sigils/links way more extensible for 3rd party things too I guess.

@neftaly

If you post from one identity from multiple devices on the same threads, do they need to be synced for sequences to work correctly?

@ansuz

yes, otherwise your feeds can fork and the network can disagree about which is the real feed.

@neftaly

Also FWIW we're now using multihash in yardstick (Conqa's centralized distributed DB)

Join Scuttlebutt now