Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Collective authoring in GigaChannels #4486

Closed
ichorid opened this issue May 8, 2019 · 6 comments
Closed

Collective authoring in GigaChannels #4486

ichorid opened this issue May 8, 2019 · 6 comments
Assignees

Comments

@ichorid
Copy link
Contributor

ichorid commented May 8, 2019

Information integration

To facilitate information integration in Tribler Channels, users must be able to change Channels data while passing it to others.

Inline editing

Every Channels entry in any channel should be editable inline. Whenever the user edits an entry, it is immediately added to the hidden "Updates" personal sub-channel (ID 1). This entry will never be replaced since the user trust themselves more than anyone ("my opinion is far more important than anyone else's").

Changes to others' channels

Changes to others' channels are sent to the original author's by gossip packets of the form:
[channel_entry_md; changed_md|new_md]. Changed and TO_DELETE entries have pending flag in the DB set to True. When the change is propagated upstream to the original author it is set to False. On receiving an update from a subscribed channel, TO_DELETE entries and changes are cleaned up if they seem to be accepted, and are set back to pending otherwise. pending changed entries are gossiped as normal, possibly propagating through the network and reaching the original author through other peers.

Overall, the network should be in the state of a constant "creative chaos" in the sense that there will be no guarantees on eventual consistency. The same is true for the human mind: conflicting thoughts constantly arise in it, tides of idle thoughts wander through it, yet most of the time it is able to function properly.

Sybil defense

To prevent Sybil attacks and spam, Tribler Channels should employ some automated information filtering mechanism. In other words, automated attacks can only be beaten by automated defense. This defense can be provided by prioritizing information updates with higher Channels Trust score.

Pull-based gossip

Information transfer in the Lightnet should be based exclusively on pull-based, or in other words, "push-request"-based gossip. Pull-based gossip ensures that no direct Sybil attack is possible. As soon as social connections are settled, group selection starts filtering out bad actors and practices. Any person can comment and change any element of other's channel, but only subscribed peers ("friends") will ask for these changes/comments and accept them.

New Arrivals feed

Tribler home screen should feature a Facebook-like "New Arrivals" feed dynamically showing the most recent changes in the subscribed channels, sorted by the Channels Trust score.

Approval of changes

If Tribler would receive a conflicting entry from one of the "liked" peers, the change will be suggested at the "My Channel" page. If the user approves it, the change is signed by their public key.

@synctext
Copy link
Member

synctext commented May 8, 2019

What is exactly the problem with duplicates?
Storage?

@ichorid
Copy link
Contributor Author

ichorid commented May 9, 2019

There are numerous problems with duplicates, namely:

  • Storage. In the case of a 'fork war', DB's will blow up instantly.
  • Performance. Bigger DB's lose a lot of performance as my tests show, especially due to FTS index.
  • Gossip efficiency. If there is no selection mechanism, gossiping around duplicates drowns Matthew effect in the noise.
  • Human mind processing capabilities. Users do not want to stare at 20 copies of the same thing.

In addition, just copying around stuff produces no new integrated information. Instead, we want our network to become a giant information integration engine, akin to Wikipedia. To achieve this goal, users must get some influence on any data that they see, even if this influence will be weak and stochastic.

@synctext
Copy link
Member

synctext commented Jul 3, 2019

Crowdsourcing brainstorm for 2020

(our platform is not ready this year for sophisticated features, we need to have more mature anonymous download first!)

Making local edits to channels seems trivial to implement, but not easy from user experience perspective.
Suggesting to keep the channel owner in firm control. Each channel owner competes for eyeballs and votes with other channels. That is the driving incentive. Highly voted channels have more prominence in the GUI. @ichorid is that inline with your thinking?

To keep matters future-proof we could enable crowdsourcing and create contributions per channel. This reduces fragmentation. There is an "inbox" of incoming 1) renaming suggestions 2) new magnets to add. This inbox is as-simple-as-possible and has only a 1 week viewing history. It is more a recent suggested changes with 1) reject change and 2) accept suggestion for the channel owner.

@ichorid
Copy link
Contributor Author

ichorid commented Jul 3, 2019

@synctext , you nailed it! That is exactly how I see it. Essentially, we recreate a simplified version of the tried-and-true GitHub pull request process.

@triblerteam
Copy link
Member

triblerteam commented Apr 2, 2020

Tribler home screen should feature a Facebook-like "New Arrivals" feed dynamically showing the most recent changes in the subscribed channels, sorted by the Channels Trust score.

This is a big feature! Love to have it in Tribler! Lots of user impact and visibility. Please put that in another separate issue. With other improvements that could be the 7.6 release, while the "inbox for edits" would then be a 7.7 feature.

EDIT: never mind; #5015 Please remove the duplicate info from this ticket

@ichorid
Copy link
Contributor Author

ichorid commented Sep 28, 2021

Duplicate of #6217

@ichorid ichorid marked this as a duplicate of #6217 Sep 28, 2021
@ichorid ichorid closed this as completed Sep 28, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

4 participants