custom fanout logic

[mikestaub]

Is there a way to prevent a fanout based on data in the activity?

My use case is a privacy feature where users want to publish an activity to groupA but exclude userA, who is a follower of groupA.

Is it possible to use a custom Aggregator for this?

[tschellenbach]

Most activity feeds apply a filter at read time to deal with privacy settings. (The do it at read time, so if you change a privacy setting the feeds change immediately)

[mikestaub]

I considered doing this, but I'm using the getstream.io platform and don't want to proxy the websocket connection. It almost defeats the purpose of using the service as I will have to route all that traffic through my servers. I was hoping for a different solution.

[tschellenbach]

You can use different feeds for different privacy levels. so you could have user_private, user_friends, user_all etc. It's pretty normal to route the feed read requests via your servers btw. Stream specialized in scalable activity feeds. So the benefit is that it stays very fast when you have many users.

…

On Sun, Mar 29, 2020 at 10:39 AM Michael Staub ***@***.***> wrote: I considered doing this, but I'm using the getstream.io platform and don't want to proxy the websocket connection. It almost defeats the purpose of using the service as I will have to route all that traffic through my servers. I was hoping for a different solution. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#237 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACAZQMFWKTJLHSUBKRWWELRJ52UPANCNFSM4LWAVTNQ> .

[mikestaub]

I do have feeds per privacy level, but the feature allows users to create exclusion sets ( include friends, exclude coworkers ), so if a coworker is also in the friends group they will see the activity - when they should not.

The way I am working around this now is flattening the groups into users but that is very inefficient and defeats the purpose of the fanout.

If I proxy the feeds I will then have to implement a websockets server which is non-trivial. ( one of the benefits we get for 'free' with faye ) But it seems like there is no other way to achieve what I want with this framework.

[tschellenbach]

I don't think you need to proxy the websocket part. You could just use that as a trigger that the feed might have changed and reread from your backend. With exclusion sets you definitely need read time filters on the feed.

…

On Sun, Mar 29, 2020 at 10:52 AM Michael Staub ***@***.***> wrote: I do have feeds per privacy level, but the feature allows users to create exclusion sets ( include friends, exclude coworkers ), so if a coworker is also in the friends group they will see the activity - when they should not. The way I am working around this now is flattening the groups into users but that is very inefficient and defeats the purpose of the fanout. If I proxy the feeds I will then have to implement a websockets server which is non-trivial. ( one of the benefits we get for 'free' with faye ) But it seems like there is no other way to achieve what I want with this framework. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#237 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACAZQJCSDCFCRY4MEW3J6DRJ54DNANCNFSM4LWAVTNQ> .

[mikestaub]

But to connect to the websocket don't I need to pass a token to the client? Then the user can use that token to theoretically read the feed manually and see all the activities, bypassing the proxy.

[tschellenbach]

You are right, that's a tricky problem. Alternatively you could connect Stream's webhook to a serverless lambda function, apply your privacy logic and use something like Pubnub/Pusher for realtime only.

…

On Sun, Mar 29, 2020 at 11:02 AM Michael Staub ***@***.***> wrote: But to connect to the websocket don't I need to pass a token to the client? Then the user can use that token to theoretically read the feed manually and see all the activities, bypassing the proxy. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#237 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACAZQNCICX7ERIW6VFCDOTRJ55LJANCNFSM4LWAVTNQ> .

[mikestaub]

That is probably what I will do. It's unfortunate I have to lose the realtime support of getstream to achieve this. Using Pubnub will increase the cost of the service.