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

Decentralize PAT-Facebook servers to resist banishment by Facebook, diffuse power, and distribute trust #72

Open
meitar opened this Issue Oct 4, 2013 · 2 comments

Comments

Projects
None yet
3 participants
@meitar
Owner

meitar commented Oct 4, 2013

This is an umbrella ticket for general discussion related to Milestone 3, the first version of which is:

PAT-Facebook functions as a distributed, decentralized, federated system in order to reduce dependance on a central (canonical) database and to further diffuse the power server operators hold by allowing people who do not trust a particular instance's server operators to use any of a number of other running instances instead.

  • A browsable directory of PAT-Facebook installs exist that users can use to locate an instance they feel they can trust.
  • PAT-Facebook instances selectively share information among themselves, on behalf of their users, such that a user of one instance can still see (shared) alerts when querying their own install. (I.e., if User A reports User B to Instance 1, User C will see B "red-boxed" when querying Instance 1 for alerts on that user. However, if User A instead reports User B to Instance 2, User C should still see User B red-boxed when querying Instance 1, if User A permitted this visibility.)

Infrastructural questions that immediately come to my mind are:

  • The most sensitive data is the "report text" itself, but even metadata such as its visibility could be exploited by malicious server operators. How do we ensure such information is only propagated as the user wishes?
  • What would a simple, intuitive interface for the above look like?

This also means we'll have created a whole new type of "user": server operators, sysops, "podmins" (to borrow a phrase from the Diaspora project), or whatever other name we want to give them. What are the social and technical implications of the creation of this new type of user and what are some possible defenses against abuse of this system by this type of user?

@abiggerhammer

This comment has been minimized.

Show comment
Hide comment
@abiggerhammer

abiggerhammer Jul 21, 2014

This is a note to myself to do a lit search in the p2p and anonymity literature for existing discussion of the question in the last sentence of this ticket.

This is a note to myself to do a lit search in the p2p and anonymity literature for existing discussion of the question in the last sentence of this ticket.

@exiledsurfer

This comment has been minimized.

Show comment
Hide comment
@exiledsurfer

exiledsurfer Jul 21, 2014

What would a simple, intuitive interface for the above look like?

a node diagram displaying the relationships between each user, clicking on the individual user node calls up a permissions dialog w/ a granular tree including all shareable elements w/ individual sharing setings.

What would a simple, intuitive interface for the above look like?

a node diagram displaying the relationships between each user, clicking on the individual user node calls up a permissions dialog w/ a granular tree including all shareable elements w/ individual sharing setings.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment