Skip to content

componentLikeButton

Patrik Schmidt edited this page Oct 27, 2013 · 38 revisions

Responsible Developer

  • Patrik Schmidt
  • Jonas Kunze

Introduction

The Like-Button can be embedded by other websites. Nearly all Entities (which implement the interface likeable) within Metalcon also have a Like-Button. Once a user clicks a like button the system will share this information with his social environment and subscribe the user to information provided by this entity.

Terminology

Proposals for the namings:

  • like (verb): moshup (mixture of mashup and mockup)
  • dislike: moshdown

Example

  • user1 clicks the Like-Button on the page of user2
    • The social graph compose an edge between the nodes of user1 and user2
    • Meaning: user1 is friend of user2 and thus following him (not vise versa as the graph is not directed!)
  • user1 clicks the Like-Button on the page of the band foobar
    • Meaning: user1 is a fan of the band foobar

More semantic definitions can be found here: semantic meaning of like

The LikeButton API will be widely used by other components/services to gain informations within the social context

  • recommendations
    • friends, bands, venue, news
    • recommendations for tagging images
  • interaction with newsstream ?
  • improved search results ?
  • Search
    • Search results that someone in your social graph likes are stored in your personalized search index, yielding higher scoring.
    • For each search item displayed, we want to display friends that like it.
  • what more ?

Please fill in your service, if you will use the Likebutton API

API

Requests

TODO: Define requests with appropriate parameters and quick responses in case of an error

The LikeButton API provides basic operations with the social graph to determine different metrics, link nodes (called entities) and retrieve common interests/friends or in general entities.

Method Signature Description
log void log(long muid, long muid) where uuid1 and uuid2 are entity-ids
like (write) void like(long muid1, long muid2, ENUM VOTE) create new link between uuid1 and uuid2 in the social graph. ENUM VOTE features VOTE.UP, VOTE.DOWN, VOTE.NEUTRAL
commons String getCommons(long muid1, long muid2) retrieves all common entities (e.g. bands) between two given entities (e.g. users)
like (read) String getIn(long muid, int timestamp) retrieves all incoming nodes to given entity (e.g. which entities likes me/are befriend with me). Only likes with a timestamp >= the given timestamp is returned. If timestamp==-1 all nodes liked since the last request is returned
String getOut(long muid, int timestamp) retrieves all outgoing nodes from given entity (e.g. which entities do I like, am I befriend with). Only likes with a timestamp >= the given timestamp will be returned. If timestamp==-1 all nodes liked since the last request is returned
likedLikes String getLikedLikes(long muid, int timestamp) returns the concatenation of all getOut(friendUUID, timestamp) with friendUUID iterating through the list returned by getOut(uuid, 0)

Errors

The following error messages will be returned (as JSON objects) in case that an request is malformed or provide invalid arguments:

Shortcode Error Description
malMUID { Error: muid identifier is malformed } MUID is malformed (wrong syntax, not the required length) and/or not known by the MUID service.
missingMUID { Error: muid identifier is not given } MUID is missing.
malVote { Error: vote is malformed } vote argument is malformed and can not be interpret.
missingVote { Error: vote is not given } vote argument is missing.
malTimestamp { Error: timestamp is malformed } timestamp argument is malformed and can not be interpret.
missingTimestamp { Error: timestamp is not given } timestamp argument is missing

Detailed description

All described entity identifiers (uuid) are Metalcon Unique Identifiers (MUID).

log

void log(muid1, muid2) where uuid1 is the user-cookie ID (requested from the browser) and uuid2 is the entity-cookie ID (also requested from the browser).

Request
HTTP/1.0 GET somedomain/commons/like?muid1=&muid2=
Accept: text/plain;
  • Logs standard interactions (pagevisits?, frequency?) with e.g. (non)-loggedin users.
  • Will be invoked during all requests above (like, common, getOut, getIn).

like (write)

void like(long muid1, long muid2, VOTE.UP | VOTE.DOWN | VOTE.NEUTRAL) and void unlike(long muid1, long muid2)

QUESTION: Shall void like(long, long, VOTE.NEUTRAL) act like void unlike(long, long)? In this case the class like could handle likes and unlikes

Creates a new edge to the social graph between uuid1 and uuid2. Will be invoked when like-button is pushed. Furthermore, the enumeration value VOTE.UP or VOTE.DOWN indicates, if a given entities will be upvoted or downvoted.

Request
HTTP/1.0 GET somedomain/likes/getout?muid1=&muid2=&vote=
Accept: text/plain;

QUESTION: Shall the method return a boolean value to enable callbacks for frontend developers?

Therefore, unlike will delete the edge between uuid1 and uuid2. This request will be logged to preserve broken links (see requirements university).

like (read)

String getIn(long muid) or String getOut(long muid)

Retrieves all incoming/outgoing edges

Request
HTTP/1.0 GET somedomain/commons/getout?muid=
Accept: text/x-json;
Response
  • getIn all incomming edges to given entity as a JSON array named with edges:
{
"muid": 213,
"edges": [ muid1 muid2 muid3 ]
}
Request
HTTP/1.0 GET somedomain/commons/getout?uuid=
Accept: text/x-json;
Response
  • getOut all outgoing edges to given entity as a JSON array named with edges;
{
"muid": 213,
"edges": [ muid1 muid2 muid3 ]
}

commons

String getCommons(long muid1, long muid2)

Request

HTTP/1.0 GET somedomain/commons/getcommons?muid1=&muid2=
Accept: text/x-json;
Response

Retrieves all common entities (e.g. bands, friends, ...) between two given entities as a JSON array named with commons:

{
"muid-from": 213,
"muid-to": 42
"commons": [ muid1 muid2 muid3 ]
}

LikedLikes (aka likes of friends/entities)

String getLikedLikes(long muid, int timestamp)

Request

HTTP/1.0 GET somedomain/likes/likedlikes?muid=
Accept: text/x-json;
Response

Retrieves all ids to likes from entities (e.g. bands, friends, ...) from your ego-network as a JSON array named with likes:

{
"muid": 213,
"likes": [ muid1 muid2 muid3 ]
}

Datamodel

Graph

Jonas: Please provide some information about the graph datamodel

Statistics

10mio uri (big metal site has about 100k URI and we have about 100 metalsites.)

metalhammer has about 100 requests per second we assume metal hammer has 2.5% market share ==> 4k request per sec

we assume 1M metalfans in Germany (certainly it won't be more)

150B per request (64Byte cookie + 64Byte uri + timestamp + additional stuff)

HTTP Logging: 4k req / sec * 3600 s * 24 / day * 150 Byte --> 330MB logs pro tag --> 120 GB per year

This calculation comes down to 350 requests per user per day

this seems even large taking into consideration that in metal.de a user creates about 10 page views per visit.

Assuming that every metalcon user (see facebook stats on Wikipedia) fires 3 likes per day. This leads to following calculation: 1000M likes per year / (360 days * 24h * 3600s) --> aprox. 50 write requests triggered by likes

we did not take into consideration: 9k band websites and 2k venue websites

a band website could embed one global like-button or on each of their web pages.

###venue

max. 30 events per month --> aprox. 300 events per year --> 1 events (per day) * 2k venues --> 2k requests per day --> 85 requests per hour

  • each event provides a like-button

Requirements

  • Fans: share information with social environment
  • Fans: beginner friendly (metalcon already knows what content people surfed on in the past)
  • Band / Venue: wants to know fans
  • Band / Venue: Promotion
  • University: usage behavior / high scaling system (handling many http requests is an interesting research question)

Page metrics from other websites

based on google indices

metal.de: 368.000 pages

  • based on their media factsheet
    • 352.000 PageImpressions / month -> 10000 per Day -> 10 per second

metal-hammer.de: 158.000 pages

  • factsheet
  • 4.918.812 PageImpressions / month -> 170000 per Day -> 120 per second

metal-inside.de: 83.000 pages powermetal.de: 437.000 pages metal1.info: 20.000 pages

requirements

components

  • data storage
  • entry point (load balancer)
  • stupid recommender
    • (who of my friends likes this entities?)
    • who in general likes this page (how many)
  • AI recommender
    • (you might also like … (friend, band, city, web site,...))

open questions

  • how many estimated requests will have to be handled (read/write/disk access)
  • what are the different domains/modules/services within this component
  • on which services do the like-button rely on
  • concerning security
    • what are common attack vectors
    • how to prevent them

Features

  • tracking users on different sites which implemented our metalcon like-button
  • display like button with personal information
    • obtain User ID
    • gather context specific information

If user presses the like-button

  • assign entity to users "preferences"
  • maybe update newsstream of users friends

Technologies

Clone this wiki locally