Feedback: Buddy System Difficulties

Post here your questions about SFS2X. Here we discuss all server-side matters. For client API questions see the dedicated forums.

Moderators: Lapo, Bax

Void*
Posts: 75
Joined: 15 Feb 2021, 13:49

Feedback: Buddy System Difficulties

Postby Void* » 29 Nov 2022, 14:48

This really is just to give some feedback regarding the ability to use the built in Buddy API for anything more complex than a "favourites" system.

In our application, we require users to Accept a friend (buddy) request in order for them to appear in each other's lists. If the invited user declines, then the first user should not have them in their Buddy List.
This is important because Online Status can be "weaponised". So I went ahead and implemented a set of filters and event handlers that run to ensure that when you "AddBuddy", the other person has to accept it and you cannot add offline/blocked players. I looked at the Temporary Buddies, however, that still updates their online status (which we *do* want to keep track of).

I then wanted to implement a Block list. If a player gets a bit spammy or toxic, we want to just add that player to a block list and filter out any messages/invites they send. Now here is where my previous implementation causes a direct conflict with this requirement. In order to *Block* a user, they must in fact be added to the buddy list **first**.

Given my implementation of requiring 2nd party consent, this means it's not possible without circumventing the entire system. Essentially, creating custom extension requests to replace AddBuddy and BlockBuddy that handle the whole handshake. In order to prevent abuse, I have also had to add SysFilterChain blocks if I even detect those calls coming in. (This is due to the fact you can protoype the websocket object in Unity WebGL and just send whatever commands you want via the JS console)

This isn't going to be an impossible problem to work-around, however, I wanted to leave this feedback here. Consent driven friend requests and one-way blocks are becoming "the norm" in the gaming industry. The fact that the system doesn't support this out-of-the-box I actually found quite surprising.

If you have any questions feel free, otherwise, thank you for reading.
User avatar
Lapo
Site Admin
Posts: 23008
Joined: 21 Mar 2005, 09:50
Location: Italy

Re: Feedback: Buddy System Difficulties

Postby Lapo » 09 Dec 2022, 10:11

Hi,
thanks, I do have some questions.
In the first paragraphs you said you have implemented a system that requires a mutual agreement between 2 users to become buddies.

If that's the case I don't understand what is the problem with the "block lists", given I can only receive spam from people I have in my list already.

Given my implementation of requiring 2nd party consent, this means it's not possible without circumventing the entire system.

This is the part that I find contradictory. Maybe you can clarify what you mean by that.
If Users are mutually friends, then they can block each other at any time if one gets toxic or spammy.

Essentially, creating custom extension requests to replace AddBuddy and BlockBuddy that handle the whole handshake. In order to prevent abuse, I have also had to add SysFilterChain blocks if I even detect those calls coming in.

The idea of the BuddyAPI is to provide a series of building blocks that you can combine together (for example with the Invitation system) to create a "Friend List" as simple or complex as you need.

I am not sure you need SysFilterChain that much. Typically what you want to do is disable the standard, client-based AddBuddy and RemoveBuddy requests (which is done via Privilege Manager). Then you can receive those requests as Extension calls and add your own logic to the AddBuddy and RemoveBuddy calls on the server side.

Thanks
Lapo
--
gotoAndPlay()
...addicted to flash games
Void*
Posts: 75
Joined: 15 Feb 2021, 13:49

Re: Feedback: Buddy System Difficulties

Postby Void* » 19 Dec 2022, 13:56

Apologies for getting back to you so late;

The problem was with weaponised online status, not spam. I won't get into the intricacies of our game mechanics, but part of the game is stealth related. Knowing if a person is online/offline at the moment they change status was a big advantage.

When adding a buddy using the existing API, they are automatically added, whether the user is online or not, as it just adds that string to the list. So if player A adds player B whilst player B is offline, player A gets the notification when they come online and player B then has to somehow figure this out and then block player A. It's a bit of a mess for our use case, and we would have to figure store offline requests etc. We got around that specific issue with sysfilters on the AddBuddy call.

This all works as intended as was originally written. My problem was that I wanted player B to provide consent before they were added to player A's buddy list.

To work around this we did eventually just disable AddBuddy and RemoveBuddy in the privilege manager, re-writing them to be Extension requests. It just seemed a shame that there wasn't something we could utilise, or enable, to allow the second party consent model.


As I mentioned before, this isn't a complaint or anything. This is just our use-case. Here is our feedback on using it to do what we wanted. We thought you might be interested on how different people use parts of the system :)

Return to “SFS2X Questions”

Who is online

Users browsing this forum: No registered users and 52 guests