Feedback on Freechains design

[arcalinea]

Thought I'd leave my comments as your first issue!

• Envisioning everything as a “chain” is nice, it’s like Matrix meets ssb. Was thinking about how a 1 to many social network on Matrix would work, and basically you just reframe the pubsub “rooms” as “topics”, and a user’s feed is a room/topic they control.
• Content doesn’t appear to be mutable, since posts in a chain are all hash-linked. This is something I think ssb suffers from - people like to have the option to at least delete, if not edit, posts on social media. Maybe you could make single-writer feeds mutable. I once played with a proof-of-concept of this with posts stored by timestamp in a merkle tree.
• You use a custom hash format? Could be worth using something like multihash which is designed for upgradeability
• Since you’re using a hash-linked data structure though, why not go ahead and use IPLD? You could also use libp2p to handle p2p networking, and then you would basically be compatible with the IPFS ecosystem - using the IPFS DHT is optional. I’m really surprised there’s not a good p2p social network on IPFS yet, it’s very feasible.
• How do you map human-readable usernames to cryptographic public keys?
• Attempts at fully p2p reputation systems are very much needed, but the results of incentive engineering are difficult to predict. From my perspective, this reputation system seems to have two main drawbacks: hard to bootstrap, and anti-viral. It’s hard to imagine it performing well in a sparse network scenario where there are few people around to “like” the posts of newbies, and new users would easily get discouraged and leave if their messages don’t show up for months. Also, losing reputation for giving out likes would lead people to be stingy with their likes, impeding network growth. You could change the reputation system so the post-suppression effects don't kick in until you reach a certain scale (measured in number of posts, activity, or peers), so there isn't unnecessary friction at the beginning. For example, Aether has a whole voting governance system for moderators, but it doesn't kick in until a community is consistently active, and in actuality it hasn't kicked in yet on any communities because the network is still so small. Spam is a real problem at scale, but in the very beginning any activity is good activity.

[fsantanna]

1. Using the same concept for multiple arrangements simplifies a lot the API. I hope it works!
2. Deleting (which I believe is important) is already possible by disliking your own post. I'm not sure if a mutable data structure would be beneficial for the same reasons you commented as disadvantages in your link. An alternative would be to implement edits on top of the protocol, maybe a back link with a patch to the original post applied at the application level.
3. Yes we should. I'll open an issue.
4. IPLD? Probably yes. I know it exists but didn't look closer. lbp2p? I'm not sure where we would use it exactly. Freechains fits completely under 2k locs in Kotlin, the daemon/local/reps/files everything. The actual p2p dynamics is external to it, we only export the "send"/"recv" API which receives a peer it connects directly.
5. We don't directly. The Android dashboard allows to do this map by hand and writes it to a "configuration chain" that can be reloaded in all your other nodes. But it is external to Freechains.
6. Yes, very difficult to predict, so I'll just explain the design decisions. The creator receives initial reputation to bootstrap the chain (maybe to little reps?). S/he has incentives to like newbies posts because increasing the number of users is the only way to increase the chain economy, which is of her interest. Also, reps expire after a period, so they must be spent somehow, better to dis/like something already in the chain. Ultimately, users want a good discussion environment, this is also an incentive to participate with dis/likes.