Idea

There has been one other discussion on Guilds in PlayFab, over here: https://community.playfab.com/hc/en-us/community/posts/207524857-Guilds. In it, we talked about one way in which you can make guilds work in our system right now.

In addition though, we do plan to add a Guild feature in future. We haven't scheduled that as yet, as it hasn't bubbled up in our priority stack-rank yet. We prioritize in part based on feedback from our community, which is why we have the Feature Requests forum (so thanks for your post!). As people vote on the various features requested, that helps to give us a better view on what things are most important to our community.

For notifications, we currently have Push Notifications available, which would allow you to message players at any time (whether or not they're signed into the game), and you could use a Photon Room as a Guild/Clan chat space for any players online.

As far as online status is concerned, because we use a Web API model (as opposed to a socket-based connection), we don't really know that a player hasn't disconnected if we haven't heard from them for a while. We are looking into the possibility of moving to a different session model which would have this concept, but it would have to consider a user as "disconnected" after a period of no messages, which wouldn't be accurate for some titles (where no messages come from the client during gameplay), so we're evaluating possible approaches currently.

Thank you for the fast and detailed answer.

Ok I did not see the shared data in the UI and have overlooked it in the API. I see how I can do it now thanks. This said, are there plans to have a UI for the shaded data management?

Also I see 

Could you tell me what the limits are?

Regarding the push notifications, I believe it doesn't work on desktop and console platforms no?

As for the online status, I understand. I guess you can either add a heartbeat function to your SDK in case no msg has been sent for a while or perhaps have a socket based connection dedicated to this feature. This would also allow all kinds of real time notifications through it in the process. Anyway, considering how nice PlayFab looks, I'm sure you guys will have the right solution ^^

Hmmm... I can see that our limits page (playfab.com/limits) needs to have some additional detail. I'll open a bug with the doc team on that.

The answer is that for Shared Group Data, the max Key name length is 1KB (actually, this is the max Key length through all systems) while the max Value length is 100KB. And yes, we do plan to make this something you can view/edit in the Game Manager in a future update.

And you're correct - Push Notifications are specific to mobile platforms. An equivalent doesn't exist for PC and console, though you do have the option to email players (always making sure they've opted in, of course), and you can use your Publisher-level data to store info which allows you to message players cross-game, if you have multiple games in the service (so, if they're playing title A, you can have Publisher level data which tells you to inform them about something in title B).

For online status, you're exactly right - heartbeat is indeed one of the things we're considering. Having more session-based connections will also allow us to provide the option for only-one-login (so, if a player signs in on multiple devices, only the most recent is valid), so it's something we're looking into for a future update.

Alright great thank you.

If you have a heartbeat, I'm wondering if you could use the http answer to notify the user that a notification is awaiting to be pulled.

Say a player sends a friend request, the notification would be stored in the target player's notification list. Later when that player client does his heartbeat he will find out he should pull his notifications list.

Of course there would be a delay according to the heartbeat speed but if you add a bit on all API operations (say in the HTTP heather) you could furthe reduce that delay?

Anyway, thanks again and have a great day!

Yes, we're planning on having a more general-purpose messaging system, which may well leverage the heartbeat in that manner.

The issue with overloading the header info to contain this sort of thing is that it would be extra data returned on each call, then - which could be an issue for some users, due to data limits/costs.