-
Notifications
You must be signed in to change notification settings - Fork 10
componentLikeButton
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.
-
user1
clicks the Like-Button on the page ofuser2
- The social graph compose an edge between the nodes of
user1
anduser2
-
Meaning:
user1
is friend ofuser2
(and vise versa if the graph is not directed)
- The social graph compose an edge between the nodes of
-
user1
clicks the Like-Button on the page of the bandfoobar
-
Meaning:
user1
is a fan of the bandfoobar
-
Meaning:
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
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(String uuid1, String uuid2) |
where uuid1 and uuid2 are entity-ids |
like (write) | void like(String uuid1, String uuid2, ENUM VOTE) |
create new link between uuid1 and uuid2 in the social graph. ENUM VOTE features VOTE.UP , VOTE.DOWN , VOTE.NONE
|
commons | String getCommons(String uuid1, String uuid2) |
retrieves all common entities (e.g. bands) between two given entities (e.g. users) |
like (read) | String getIn(String uuid) |
retrieves all incoming nodes to given entity (e.g. which entities likes me/are befriend with me) |
String getOut(String uuid) |
retrieves all outgoing nodes from given entity (e.g. which entities do I like, am I befriend with) |
All described entity identifiers (uuid) are Metalcon Unique Identifiers (MUID).
void log(uuid1, uuid2)
where uuid1
is the user-cookie ID (requested from the browser) and uuid2
is the entity-cookie ID (also requested from the browser).
- Logs standard interactions (pagevisits?, frequency?) with e.g. (non)-loggedin users.
- Will be invoked during all requests above (like, common, getOut, getIn).
void like(String uuid1, String uuid2, VOTE.UP or VOTE.DOWN)
and void unlike(String uuid1, String uuid2)
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.
QUESTION: What will be the default behavior where voting is not applicable?
I added the enum value VOTE.NONE
!
This value will be used every time an up- or downvote is not applicable.
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).
String getIn(String uuid)
or String getOut(String uuid)
Retrieves all incoming/outgoing edges
- getIn all incomming edges to given entity as a JSON array named with edges:
{
"uuid": 213,
"edges": [ uuid1 uuid2 uuid3 ]
}
- getOut all outgoing edges to given entity as a JSON array named with edges;
{
"uuid": 213,
"edges": [ uuid1 uuid2 uuid3 ]
}
String getCommons(String uuid1, String uuid2)
Retrieves all common entities (e.g. bands, friends, ...) between two given entities as a JSON array named with commons:
{
"uuid-from": 213,
"uuid-to": 42
"commons": [ uuid1 uuid2 uuid3 ]
}
The information in this section are currently for benchmarking purposes only. Further specification is still pending
Benchmarking graph is stored as plain csv file (directed)
1,2
1,3
1,5
2,1
2,5
2,4
3,1
3,5
4,2
4,5
5,1
5,2
5,4
Each document will store a StringField which refers to the node uuid
. All additional fields in this document (here entitled with entity1, entity2 and so on) are the nodes in the graph which are linked directly to the node uuid
Document |
---|
uuid |
entity1 |
entity2 |
entity3 |
... |
After the query of lucene computed all common entities between uuidfrom
and uuidto
they will be stored with MongoDB to ensure(?) fast lookup-times.
Document |
---|
uuidfrom |
uuidto |
entity1 |
entity2 |
entity3 |
... |
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
- 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)
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
- logging http access
- interaction with like button (like something retrieve friends who like!)
- retrieval: as often as http logging (only if user cookie is set)
- create: vary rare
- interaction with news feed
- building a strong (almost realtime) recommender system: http://ssc.io/deploying-a-massively-scalable-recommender-system-with-apache-mahout/
- 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,...))
- 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
- 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
- Patrik