Drecs NPM | npm.io

drecs

This distributed recommender is accessed by running an interactive shell interpreter.

Recommendation link path (create graph on link to)
- check to see if hits a whitelist
can we assign a whitelist ground truth score to each content to evaulate linked content
- asymetry in with truth in network (truth can be less "sexy")
  - true argument is more quality
  - misinformation hurt by linking to true content
Cluster things by recommendations
- extract information from liked recommendations to determine something
rate current recommendations to see if you like fake news

share peer list with people close to you?
- within a certain ping time
- network coordinates
- oasis project?

What's next

if you're on a certain page show recommended links in a different color
at current url, show me next recommendations
electron browser that helps you populate recommended list (like decentralized stumble upon)
scrape massive repo of sites for initial content
would sharing with randomly matched people help you at all?

Keep existing more usuable but make more privacy? somehow inget more content

error when adding URLS with - causes adding to table to break

Gossips all rated urls without any identifier across pubsub so that peers can discover more URLS to explore without any central source of seeding

can decide if peers wants to add to blacklist or rate
don't share blacklisted urls because can't auto add (be easy to blacklist good websites) and blacklisting on own would require user to view site (which we don't want them to do if actually a bad site)

FINISHED COMMANDS

<required> [optional]

Forbid user value of me (overloaded functionality)

secret is a randomly generated 64 character string

IPFS files encrypted using aes-256-ctr from crypto module

When loading content from IPFS address (either ratings or blacklist) it is pinned locally (makes easier when restoring from backup)

add rating <url> <rating> (removes from possible recommendations) (rating from 0-5)
share ratings (shares all items in ratings added by current user) -> access_token (if this is meant to be open, just share secret -> doing so does not impact personal backup)
load ratings <user> <access_token> (if already ratings in the system it only adds new ratings and overwrites existing if new exist)
- Why have importing user define USER?
- automatically pins
backup (backed up automatically after each operation, this just returns current backup) -> access_token
restore backup <access_token> (clears all saved data...required at startup of interpreter, which maintains no state when closed other than what is in .jsipfs directory)
show imports (user and access token)
show ratings [user]
show users
show IPFS bandwidth
show IPFS peers
get recommendation -> url, likelihood
lastrec rate <rating> (rates last recommendation if exists)
lastrec open (opens last recommendation if exists)

CURRENTLY WORKING ON

add blacklist <url> (automatically matches against all urls that contain [url])
share blacklist (shares all items in blacklist added by current user) -> access_token
load blacklist <user> <access_token>
show blacklist [user]
show blocked content (show all urls blocked by blacklist in rating)
delete ratings <user>
delete blacklist <user>

FILE TYPES

All file types are JSON that is encrypted and stored in IPFS

Ratings File

[[url_1, rating_1], ... , [url_n, rating_n]]

Blacklist File

[[url_1], ... , [url_n]]

Backup File

{
  ratings: {
    imports:[[user_1, access_token_1], ... , [user_n, access_token_n]],
    me:[[url_1, rating_1] , ... , [url_n, rating_n]]
  },
  blacklist:{
    imports:[[user_1, access_token_1], ... , [user_n, access_token_n]],
    me:[[url_1] , ... , [url_n]]
  }
}

FAQs

Why can't you share other users ratings or blacklist?
- it is important to know where you got information (sets an insecure practice to refer traffic improperly)
  - ex: I have the recommended articles from CNN when they are just pages I get ad revenue from when you visit
Abstract IPFS address and secret to "access token"