Following neutral games

[tttppp123]

One of the main thing I use the app for is spectating on games. For example at the moment I am clicking through all the Twenty Twenty games to see if there have been new moves or public press.

I initially thought that we could just add an extra column to each game of neutral parties who should be notified at the same time as participants, but more recently I've thought that it would be better to have something more like an RSS feed. I'm not certain either way yet though.

The other reason I've been thinking about this is that Backstabbr has a cool Discord bot which posts in when there's a new phase in a particular game. I had a quick look at the API and they support webhooks, so maybe we could add one of those.

Anyway before starting anythig I wanted to gather thoughts about use cases that I've missed or suggestions about what will be expensive (e.g. will polling for RSS scale ok?)

[Martin Bruse]

I believe most other HTTP requests would be as expensive as the RSS requests, so the cost should be fine.

Maybe generate a code for each user that they use as token in the RSS request, so that we sort or require a Diplicity user account for RSS as well?

The problem with the webhook is rather a config problem - how do we make a particular game have a particular webhook?

Maybe during setup of the game we could have "advanced options" where you can add a webhook to execute on phase or "everyone channel"-changes?

--
You received this message because you are subscribed to the Google Groups "diplicity-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to diplicity-de...@googlegroups.com.
To post to this group, send email to diplic...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[tttppp123]

Ok - I had a look at adding RSS feeds today. At first I was thinking of adding a new method to each game:

http://localhost:8080/Game/{game-id}/Rss

However there are a couple of things that I didn't like:

1. There is some clever handling of logged in users here. Obviously we don't want to provide open access to unresolved moves.

2. I want RSS feeds to be public, and didn't want users to accidentally share their token.*

So instead I'm planning to add a couple of new routes:

http://localhost:8080/Rss

http://localhost:8080/Rss/Game/{game-id}

This then leaves room for different RSS feeds that I haven't thought of yet.

I think a public RSS feed will provide enough to get Discord updates working too - as there are already RSS bots for Discord. Hence I hope this will kill two birds with one stone.

I didn't decide what should be in the RSS updates yet, but a map showing the orders would be amazing.  I think RSS can carry SVG (no idea if my RSS reader can render it though), but the orders are currently applied via JavaScript in the client.  Consequently I might start with something less glamorous like a link to the latest phase.

* For "users" read "me".  Actually - I think there's still a good chance of sharing my token by mistake here, but meh.

[Martin Bruse]

It sounds mostly good.

I believe it should be fairly easy to provide the public info (minus email addresses etc) using either URL. Preferably cached in the App Engine memcache or something similar, since the RSS can't be as sensitive to updated data.

Just make sure to remove any personal info like emails or such, and of course chat channels that aren't "everyone".