Skip to content

Latest commit

 

History

History
335 lines (316 loc) · 14.7 KB

project.org

File metadata and controls

335 lines (316 loc) · 14.7 KB
Raw

Project: Distributed Social Networking

Description

The web is fundamentally interconnected and peer to peer. There’s no really great reason why we should all use facebook.com or google+ or myspace or something like that. If these social networks came up with an API you could probably link between them and use the social network you wanted. Furthermore you might gain some autonomy.

Thus in the spirit of diaspora https://diasporafoundation.org/ we want to build something like diaspora but far far simpler.

This blogging/social network platform will allow the importing of other sources of posts (github, twitter, etc.) as well allow the distributing sharing of posts and content.

An author sitting on one server can aggregate the posts of their friends on other servers.

We won’t be adding much in the way of encryption or security to this platform. We’re keeping it simple and restful.

Choose at least 2 other groups to work with

Project Parts

  • Part 0 - sign up a repo
  • Part 1 - 1/2 way implementation
  • Part 2 - Connect with Groups
  • Part 3 - Finish it off!

Collaboration

  • You may consult with others but the submission should be your own team’s source code.
  • You may work with 4 other students (groups of 5)
  • Work will be submitted together
  • Collaboration must be documented in the README.md file
  • Any external source code must be referenced and documented in the README.md file
  • You make collaborate/consult with other groups in order to get your webservices to integrate with each other

User Stories

  • As an author I want to make posts.
  • As an author I want to edit posts.
  • As an author, posts I create can link to images.
  • As a server admin, images can be hosted on my server.
  • As an author, posts I create be private to me
  • As an author, posts I create be private to another author
  • As an author, posts I create be private to my friends
  • As an author, posts I create be private to friends of friends
  • As an author, posts I create be private to only friends on my host
  • As an author, posts I create can be public
  • As an author, posts I make can be in simple plain text
  • As an author, posts I make can be in markdown (commonMark is good)
  • As an author, I want a consistent identity per server
  • As a server admin, I want to host multiple authors on my server
  • As a server admin, I want to share or not share posts with users on other servers.
  • As a server admin, I want to share or not share images with users on other servers.
  • As an author, I want to pull in my github activity to my “stream”
  • As an author, I want to post posts to my “stream”
  • As an author, I want to delete my own posts.
  • As an author, I want to befriend local authors
  • As an author, I want to befriend remote authors
  • As an author, I want to feel safe about sharing images and posts with my friends – images should not publicly accessible without authentication.
  • As an author, I want un-befriend local and remote authors
  • As an author, I want to be able to use my web-browser to manage my profile
  • As an author, I want to be able to use my web-browser to manage/author my posts
  • As a server admin, I want to be able add, modify, and remove authors.
  • As a server admin, I want to be able allow users to sign up but require my OK to finally be on my server
  • As a server admin, I don’t want to do heavy setup to get the posts of my author’s friends.
  • As a server admin, I want a restful interface for most operations
  • As an author, other authors cannot modify my data
  • As an author, I want to comment on posts that I can access
  • As an author, my server will know about my friends
  • As an author, When I befriend someone it follows them, only when the other authors befriends me do I count as a real friend.
  • As an author, I want to know if I have friend requests.
  • As an author I should be able to browse the public posts of everyone
  • As an author I should be able to browse the posts of others depending on my status
  • As a server admin, I want to be able to add nodes to share with
  • As a server admin, I want to be able to remove nodes and stop sharing with them.
  • As a server admin, I can limit nodes connecting to me via authentication.
  • As a server admin, node to node connections can be authenticated with HTTP Basic Auth
  • As a server admin, I can disable the node to node interfaces for connections that are not authenticated!
  • As an author, I want to be able to make posts that are unlisted, that are publicly shareable by URI alone (or for embedding images)

Main Concepts

  • Author
    • makes posts
    • makes friends
    • befriends other authors
  • Server Admin
    • manages a node
    • allows people to sign up
    • responsible for private data :(
  • Follow
    • Friend another author without an accepted friend request
  • Friend
    • Friend another author and they accept the friend request
  • Server
    • a host that hosts authors and vouches for them
  • Restful service
    • The model of the service and its API
  • UI
    • The HTML/CSS/JS coated version user interface
  • FOAF
    • Friend of a friend

Requirements

  • [ ] Implement the webservice as described in the user stories
  • [ ] Provide a webservice interface that is restful
  • [ ] Provide a web UI interface that is usable
  • [ ] Prove your project by connecting with at least 2 other groups.
  • [ ] Make a video demo of your blog (desktop-recorder is ok)
  • [ ] Make a presentation about your blog
  • [ ] Follow the guidelines in the example-article.json for the URLs and services
  • [ ] friend querying via POSTs to http://service/friends/userid
  • [ ] friend2friend querying via GETs to http://service/author/<userid>/friends/<userid>
  • [ ] implement author profiles via http://service/author/userid
  • [ ] Enforce some authentication
    • Consider HTTP Basic Auth
  • [ ] implement a restful API for http://service/posts/postid
    • a PUT should insert/update a post
    • a POST should insert the post
    • a GET with a postfixed “postid” should return the post
    • a GET without a postfixed “postid” should return a list of all “PUBLIC” visibility posts on your node
    • implement an alias http://service/posts/postid for Winter 2015 term projects.
  • [ ] FOAF verification involves the 3 hosts of the 3 friends A->B->C assuming A B C reside on different hosts.
  • [ ] Allow users to accept or reject friend requests
  • [ ] friend requests can be made by POSTing a friend request to http://service/friendrequest
  • [ ] http://service/author/posts (posts that are visible to the currently authenticated user)
  • [ ] http://service/author/{AUTHOR_ID}/posts (all posts made by {AUTHOR_ID} visible to the currently authenticated user)
  • [ ] Images get the same protection that posts get as they are POSTS
  • [ ] example-article.json is adhered to.

Take-aways

  • [ ] 1 Working Website
  • [ ] 1 Github git repo
  • [ ] 1 Presentation
  • [ ] 1 Video

Restrictions

  • [ ] Use Python 3.6 (otherwise get approval)
  • [ ] Use Django or Flask (otherwise get approval)
  • [ ] Must run on one of the following:
    • [ ] provided VMs
    • [ ] Heroku
  • [ ] License your code properly (use an OSI approved license)
    • Put your name on it!

API Guidelines

When building your API, try to adhere to these rules for easy compatibility with other groups:

  • REST API calls may be prefixed. ie. http://service_address/api/author/{AUTHOR_ID}/posts/
  • Document your service address, port, hostname, prefix(if used), and the username/password for HTTP Basic Auth(if used) in your README so that HTTP clients can connect to your API.

Submission Instructions

Warning!!!!

This spec is subject to change!

Marking

Project Part 0

  • 1 mark
  • [ ] 4-5 CCIDs
  • [ ] 1 Github repo with a README and LICENSE

Project Part 1

  • 10 Marks (scaled to 7 marks)
  • Code Base 3 marks
    • Excellent 3: Excellent effort. Relatively consistent. At least ½ of the project implemented. Clean code
    • Good 2: Good quality. Some inconsistency. About ½ of the project implemented
    • Satisfactory 1: Codebase in places. Passes some tests. Some parts run
    • Unsatisfactory 0: Does not meet Satisfactory level
  • Test Cases 1
    • Excellent 1: System is well tested
    • Good 1: System has some tests
    • Unsatisfactory 0: test cases are inappropriate
    • Unsatisfactory 0: Missing test cases
  • UI 2
    • Excellent 2: UI Exists and is coherent. Shows evidence of planning.
    • Good 1: UI Exists. Very rough.
    • Unsatisfactory 0: UI is missing
  • Tool Use 1
    • Excellent 1: Use of at least Git is Evidence and Obvious
    • Good 1: Frequent but inconsistent use of Git, etc.
    • Satisfactory 0: Infrequent use of Git, etc.
    • Unsatisfactory 0: Lack of tool use
  • TA Demo 1
    • Excellent 1: Coherent demo, shows off features. Limited snags.
    • Good 1: Coherent demo, shows off features. Some snags.
    • Satisfactory/Unsatisfactory 0: Undemoable, weak presentation
  • Web Service API & Documentation 2
    • Excellent 2: Documented, adheres to requirements to augments them with compatibility
    • Good 1: Documented, exists, tries to adhere to requirements
    • Satisfactory 0: Some of the webservice exists
    • Unsatisfactory 0:
  • Design 1
    • Excellent 1: Adheres to standards, well designed
    • Good 1: Adheres to standards somewhat, some awkward parts
    • Satisfactory 0: Some good parts, some nasty parts
    • Unsatisfactory 0: Little effort went into documenting and designing the project

Project Part 2: The web service

  • 5 Marks
  • Web Service API & Documentation 1
    • Excellent 1: Documented, adheres to requirements to augments them with compatibility
    • Good 1: Documented, exists, tries to adhere to requirements
    • Satisfactory 0: Some of the webservice exists
    • Unsatisfactory 0:
  • Web Service Coordination 3
    • Excellent 3: Web service coordinates with 1+ other group projects successfully. Most interoperation requirements met.
    • Good 2: Web service coordinates with 1+ other group projects successfully. Most interoperation requirements met. Some snags.
    • Satisfactory 1: The basics of coordination are covered. Probably many snags.
    • Unsatisfactory 0: Coordination doesn’t work or barely works.
  • Design 1
    • Excellent 1: Adheres to standards, well designed
    • Good 1: Adheres to standards somewhat, some awkward parts
    • Satisfactory 0: Some good parts, some nasty parts
    • Unsatisfactory 0: Little effort went into documenting and designing the project

Project Part 3

  • 20 Marks
  • Code Base 3 marks
    • Excellent 3: Excellent effort. Relatively consistent. At least 90% of requirements implemented. Clean code
    • Good 2: Good quality. Some inconsistency. About 90% of requirements implemented.
    • Satisfactory 1: Codebase in places. Passes some tests. Some parts run
    • Unsatisfactory 0: Does not meet Satisfactory level
  • Test Cases 1
    • Excellent 1: System is well tested
    • Good 1: System has some tests
    • Unsatisfactory 0: test cases are inappropriate
    • Unsatisfactory 0: Missing test cases
  • UI 3
    • Excellent 3: UI Exists and works well. Shows evidence of planning. Looks great.
    • Good 2: UI Exists. Looks good
    • Satisfactory 1: UI exists. Look poor.
    • Unsatisfactory 0: UI is missing
  • Tool Use 1
    • Excellent 1: Use of at least Git is Evidence and Obvious
    • Good 1: Frequent but inconsistent use of Git, etc.
    • Satisfactory 0: Infrequent use of Git, etc.
    • Unsatisfactory 0: Lack of tool use
  • Web Service API & Documentation 2
    • Excellent 2: Documented, adheres to requirements to augments them with compatibility
    • Good 1: Documented, exists, tries to adhere to requirements
    • Satisfactory 0: Some of the webservice exists
    • Unsatisfactory 0:
  • Web Service Coordination 3
    • Excellent 3: Web service coordinates with 2+ other group projects successfully. Most interoperation requirements met.
    • Good 2: Web service coordinates with 2+ other group projects successfully. Most interoperation requirements met. Some snags.
    • Satisfactory 1: The basics of coordination are covered. Probably many snags.
    • Unsatisfactory 0: Coordination doesn’t work or barely works.
  • AJAX 1
    • Excellent 1: Uses AJAX appropriately and well (documented)
    • Good 1: Uses some AJAX (documented)
    • Satisfactory 0: AJAX not really used
    • Unsatisfactory 0: No AJAX
  • Adhering to Standards 1
    • Excellent 1: Excellent attempt at making a standards compliant website. Most things are compliant.
    • Good 1: An attempt at making a standards compliant website. Some not compliant.
    • Satisfactory: Inconsistent.
    • Unsatisfactory: No apparent attempt to meet standards.
  • Design 1
    • Excellent 1: Adheres to standards, well designed
    • Good 1: Adheres to standards somewhat, some awkward parts
    • Satisfactory 0: Some good parts, some nasty parts
    • Unsatisfactory 0: Little effort went into documenting and designing the project
  • Addressing Feedback 1:
    • Excellent 1: TAs suggestions were implemented, TA approves of implementation set.
    • Good 1: The good TA suggestions were implemented ;)
    • Satisfactory 0: Feedback ignored mostly, but some followed.
    • Unsatisfactory 0: Feedback ignored.
  • Presentation 2:
    • Excellent 2: Presentation within time, shows teamwork, promotes the application.
    • Good 2: Presentation nearly within time, some team works, reasonable presentation.
    • Satisfactory 1: Presentation exists but has problems.
    • Unsatisfactory 0: Missing or terrible presentation (lack of practice, lack of preparation, irrelevant).
  • Video Demo 1:
    • Excellent 1: Video is well presented and not boring, less than 2 minutes.
    • Good 1: Video presents the functionality and is less than 2 minutes.
    • Satisfactory 0: Video is longer than 2 minutes, or doesn’t accurately present the project.
    • Unsatisfactory 0: Video Missing