I've been working with GetStream this week and it worked as expected for the first part. However, now that I would like to move forward, I would like to create a "discover like" (like the one on Instagram by example?) feature
The thing is, I am not really sure how to achieve it. My end goal would be something like:
You have posts (from users I don't follow) in the Discover feed of the userA
UserA follow a user from the discover (owner of a post, let say UserX)
UserX activities (previous and future ones) gets forwarded to userA flat feed and disappear from discover feed for the UserA
This would means (from my understanding) following everyone when a user create an account, and then unfollow people from discover flat feed (on follow) and follow them from timeline flat feed? But it seems to be unscalable to me, isn't it?...
For now, I have 2 feeds:
- users-timeline -> flat feed containing user post (post of UserA by example)
- followings-timeline -> flat feed which follows activities on selected "users-timelines"
How could I have a third feed which would act as a discover?
Related
Let's say I want to build a system where each user has access to a notification feed and an aggregated feed, with the following groups:
user as flat feed
hashtag as flat feed
notification as notification feed
timeline as aggregated feed
We also have the following relations:
user:b follows hashtag:a
user:b follows user:a
Now consider the following situation:
If user A posts with hashtag A, I would like user B to get an activity in its notification feed (thanks to relation 1). But I also would also like all followers of user A to see in their timeline that user A did something. Then, user B will get the activity in its notification feed, and in its timeline (because of relation 2): there is a duplicate.
Is there a way to avoid this situation ?
A naive way would be to manually filter the feed and prune the aggregated activities we do not want to see. But this of course seems non optimal.
Thank you very much!
You can use discard rules to avoid activities matching one of rule from getting added to a follower's feed.
This is usually something you use to avoid own activities from showing up in your notification feed.
Here's the link to the docs on Discard Rules:
https://getstream.io/docs/#discard-rules
In examples on the Get stream Website, I see that they show examples where users are following other users and then they get to see the posts of the user they are following. How can I change this and make it so that users can follow a category(s) instead of a user and then see posts on their feed from the category(s) they are following? Currently, when I make a new post, I add a custom field to capture category id. Not sure what to do next.
I'm using the Get Stream for Laravel.
In Stream a feed can represent anything. So it can be a user, or a timeline (wall) or a category. Simply create a feed for the category and add the activities to it with the TO field. Then your user can follow the category feed.
More information about this can be found on the official docs: https://getstream.io/docs/#targetting
I'm using a flat-feed, to be able to follow and unfollow other profiles.
But as i see it, i want to group the verbs as it is possible in the aggregated-feed.
Because i want to aggregate likes to the same activity.
user2 and user3, likes image1.
user1 follow user2 and user3.
Meaning that user1 now have two activities, of users liking the same image and i want it to be displayed as one activity.
Should i handle this myself by sorting it with the foreign key and then collect the activities into one? Or can i somehow blend the flat-feed with aggregated-feed?
This How to build a news feed with aggregate and flat types? is similar, but i need to be able to follow and unfollow.
After finding out that i could combine flat-feed and aggregated-feed i came up with this setup:
In this example beneath, User2 is publishing an artwork, meaning that User2-feed now includes an activity that shows his artworks.
Shortly after User3 likes his newly posted artwork, meaning that User3-feed now include an activity that shows his like of the artwork.
User1 is following User2-feed and User3-feed which create User1-aggregatedfeed that include all activities from the two feeds, that User1 is currently following. It means that User1’s own activity will not being shown in his own User1-aggregatedfeed unless he is following his own feed, which isn’t possible.
The same artwork that is added to User2-feed is also added to Artist1-feed because the artist of the artwork is Artist1. Meaning that the same artwork is now added to two feeds that User1 is following. But activity will only be added to User1-aggregatedfeed once, because we store the “artwork publish” activity with the same foreign key.
Flat-feed combined with aggregated-feed example
I went through all tutorials and docs which stream-django provided.
And there was one thing that I could't understand.
I can't find the differences between these feed_manager methods.
# (1)
feed = feed_manager.get_news_feed('timeline', request.id)
# (2)
feed = feed_manager.get_news_feed(request.id)['timeline']
# (3)
feed = feed_manager.get_news_feed(request.id)
Could you explain the difference? Are they doing exactly same thing? timeline means flat feed, then why do we put timeline in param?
Thank you
timeline is the name of the feed group that you've created within Stream.
Once you create a feed group in Stream, you'll select the type of feed group ("flat" in this case, but can also be "aggregated" or "notification"), then, you'll name the feed group - common names are timeline/news_feed (a homepage feed showing activity from other users) or profile/user (a profile page feed showing all activities from a single user). There are no "reserved" words in feed group names.
Re: whether or not these methods are all doing the same thing:
feed_manager.get_news_feed('timeline', request.id) (1) is definitely correct. It'll fetch the feed activities for the specific timeline:1234 feed, where 1234 is most likely your user's ID.
(2) and (3) I'm not sure about - it's likely that they're doing the same thing as (1), but I'm not able to tell at the first glance at the docs.
Hopefully that helps!
I'm building an activity feed application, where a user can like/comments on each activity feed. I went through GetStream.io documentation and looks like I'll have to send the activity with object ids.
{
id:"ef696c12-69ab-11e4-8080-80003644b625",
actor:"User:1",
object:"Comment:12",
started_at:"2014-11-11T15:06:16+01:00",
target:"Feed:100",
time:"2014-11-11T14:06:30.494",
verb:"add"
}
User:1 and Feed:12 are the objects in my application database? Does it mean that, while retrieving activities, I'll have to hit my database to retrieve the complete feeds?
Say the Feed:12 had few likes and comments earlier from other users. How do I get the complete set of likes/comments on user timeline feed?
What if I want to customize the view, say I want to show all users (image, name, the profile like etc) along with comment with timestamp similar to FB? Do I need to send these attributes as additional parameters for each feed?
Thanks,
Yes, when you fetch a feed from Stream and we give you back these references like user:1 or comment:12, we expect that you'd "enrich" those details from your database.
Typically what our users do is track the name of the model (eg, user) and the user_id (eg, 1). When you get the feed and put it into a hash map, you'll iterate over the activities, pull out all of the actor attributes, and do a single lookup like select * from user where id in (1,3,5,6,9,12) so that you're only hitting your database one time for all user objects or all comment objects or whatever. Then, replace those activities in your hash map so now you'd have actor: <object for User 9> and any other attributes you'd need for your UI presentment.
Then do the same for other references you pass in the activity, and so on.
Things we DON'T recommend are putting in string references for things that could change on your side. For example, if you had actor: "user:ian" instead of my user_id, if I ever change my username later then things probably wouldn't work properly on your side.