feedback

[cblgh]

love it!!!!!

agree with staltz that you could consider dropping the seqno in favor of some kind of list of previous hashes / hash frontier thing.

re key reuse:

my inner keks says "this is a bad idea" but i've never looked into why that is X)

more interesting imo is describing how to sync keypairs across devices, as well as potentially designating a "Permanently Moved" / backup keypair in case of compromise. imo tombstone / never-sync-again state (kind of a nuclear option of gdpr's right to be forgotten) of the current feed needs to be considered and should be able to be actioned on by delegated peers, tho out of scope for this spec.

re bipf:

given the current light of re-evaluating things, have you reconsidered dom's ltp? mentioning cause simpler deps means more likely to be (correctly) implemented in other languages.

and maybe a naive question but why does the feed format have to specify the storage format? so: why not do bipf on messsages after receiving, rather than before sending. gives you flexibility for changing it later on, and imposes less constraints on implementations / database choices. so i guess my point is "specify the bytes to send, not how to store them" but then again i've got cable on my brain

re tag:

have you considered instead using a varint or similar, in case the far future needs more than 256 types of semantics? one promising candidate is https://en.wikipedia.org/wiki/LEB128

re msg id:

interesting concept! undecided whether its a good idea to truncate the hash or not, didn't read the blake3 thread too carefully. i like that you can pseudo-figure out whether a message is interesting to fetch or not based on a referenced msgid :)

re follow & block:

given this is going away from linear feeds (yes!!!) i think it is better to have add/remove messages and allow for each target of the message to drop the previous "message-opposite". an example:

sequence diagram

1. follow/add/arj
2. follow/add/staltz
3. follow/add/new-person
4. follow/add/glyph
4. follow/remove/new-person
5. follow/add/gary

grab bag of messages stored in local database after sequence 4:

follow/add/arj
follow/add/staltz
follow/add/glyph
follow/add/gary
follow/remove/new-person

i.e. follow/add/new-person has been superceded / its information is not needed to compute the resulting follow graph (by anyone) and can be dropped from the local store.

mimic the same structure for blocks.

rationale: i will not have an infinite number of follow or block messages that others need to sync. to this day, across all of my historic social media use, i have a very insignificant number of follow and block actions combined.

the amount of block messages needed in the feed concept itself is decreased further if you design for allowing a subjective moderation system similar to trustnet i.e. allow pulling in blocks/moderation actions from other feeds. these don't need to be store in your feed concept (as messages) but only in your local database, as the delegated actors engage in moderation decisions and gossip them outwards.

this enables you to have message stricter message limitations in place and doesn't force message databases to function in a particular way

[arj03]

love it!!!!!

Thanks <3

I'll respond in detail later, it is getting late here. Some very good feedback. .

re bipf:

given the current light of re-evaluating things, have you reconsidered dom's ltp? mentioning cause simpler deps means more likely to be (correctly) implemented in other languages.

Yeah bipf is the sore thumb here, seeing that we are reducing complexity :) I'll say though that bipf is not really that scary and pretty simple code. I do belive cft ended up using it in tinyssb as well.

ltp is not a good fit for the content because it is based on a schema. And I didn't want two encodings. Wait ohh that's a juicy one, since we have specific feeds, we could have a schema for each similar to p2panda. I'll have to think about that.

[arj03]

re follow & block:

given this is going away from linear feeds (yes!!!) i think it is better to have add/remove messages and allow for each target of the message to drop the previous "message-opposite". an example:

Ah yes, of course. This model is actually just edit/delete then. Thanks, great input!

I was afraid that the number of follow messages would blow up, but I think if we do something smart in the UI, like suggest or auto unfollow people that havn't been active for a year, then this look much more reasonable in the # of msgs.

[arj03]

re key reuse:

my inner keks says "this is a bad idea" but i've never looked into why that is X)

more interesting imo is describing how to sync keypairs across devices, as well as potentially designating a "Permanently Moved" / backup keypair in case of compromise. imo tombstone / never-sync-again state (kind of a nuclear option of gdpr's right to be forgotten) of the current feed needs to be considered and should be able to be actioned on by delegated peers, tho out of scope for this spec.

Agree. I remember that cft mentioned this in a earlier iteration of these things and the idea was that you posted an encrypted dead mans switch message basically saying this author is now dead. You would then write down the key on a piece of paper or something and if you ever were compromised or wanted to nuke the authors ability to be part of the network, you then reveal the key. There is a ton of edge cases in this, like at what point is the author dead. What about their messages that are part of tangles etc. So yeah, definitely out of scope for this :)

[arj03]

I moved out the 2 remaining issues.

Thank you so much for your feedback. You substantially improved this spec.