Bots and other addons

chucker · **Posted:** Sun Apr 04, 2010 4:40 pm

Christian Walther wrote:

I don’t see why or how we should or could make a difference between “3rd party addons” and “game clients”.

Why: because automation can be used for good as well as evil. Consider a single human spammer. Annoying? Sure. Easy to move on from? Probably. Now, consider a single spamming bot. Still easy to ignore, but in the time it takes to do that, he's already sent out an order of a magnitude as many messages as the human by virtue of not having to type them out manually.

How: 1) by requiring clients to signify their capabilities using an OAuth-like API key system, as OHB alluded to, and then 2) at the shard admins' discretion.

OHB · **Joined:** Wed Feb 10, 2010 12:28 am **Posts:** 1247

chucker wrote:

at the shard admins' discretion.

I'd rather not see a different API for each shard. I'd like to see something central. Down the line when there are shards, it'll all still be connected...we can PM between shards...no reason the vault can't have an API. If each shard has anything shard-specific, they can create their own separate API. But for global data, it should be a single unified API for both ease of use, expandability, security, and perhaps most importantly, sanity of developers.

Rusty_Russell · **Posted:** Sun Apr 04, 2010 5:03 pm

I don't think "central" works. It's a vault (database) that governs what is or isn't a shard. From that standpoint, it's just yes or no regarding the API, rather than flavour.

Christian Walther · **Posted:** Sun Apr 04, 2010 6:11 pm

chucker wrote:

Christian Walther wrote:

I don’t see why or how we should or could make a difference between “3rd party addons” and “game clients”.

Why: because automation can be used for good as well as evil. Consider a single human spammer. Annoying? Sure. Easy to move on from? Probably. Now, consider a single spamming bot. Still easy to ignore, but in the time it takes to do that, he's already sent out an order of a magnitude as many messages as the human by virtue of not having to type them out manually.

How: 1) by requiring clients to signify their capabilities using an OAuth-like API key system, as OHB alluded to, and then 2) at the shard admins' discretion.

I agree with all that (I don’t know what OAuth is, but I’m sure I’ll learn it in time), but what does that have to do with distinguishing “addons” and “clients”?

Are these categories even well-defined? I guess WhoM is a client (since it makes its own connection to the server) and OHBot is an addon (since it works through Cyan’s official client), but once we can build our own game clients based on Cyan’s, all kinds of in-between things become possible.

Why would we want to have different rules for the two? If you don’t want spam, then you need to disallow both spamming addons and spamming clients.

In a nutshell, what I wanted to say is that I see no point in a discussion exclusively about “addons” or “3rd parties”, as this thread appears to be. (Who’s going to be the 1st and 3rd parties in a decentralized open-source world?) Unless the original poster meant “addons” in a sense that includes what I call “clients”, but I’d consider that a strange terminology (added to what?).

chucker · **Posted:** Sun Apr 04, 2010 6:22 pm

OHB wrote:

chucker wrote:

at the shard admins' discretion.

I'd rather not see a different API for each shard.

I didn't mean that at all. I meant that the decision over allowing or banning individual bots is per-shard, just like it is the case for human explorers

chucker · **Posted:** Sun Apr 04, 2010 6:24 pm

Christian Walther wrote:

Are these categories even well-defined? I guess WhoM is a client (since it makes its own connection to the server) and OHBot is an addon (since it works through Cyan’s official client), but once we can build our own game clients based on Cyan’s, all kinds of in-between things become possible.

I'm not sure why you're muddling orthogonal facets of a client — on the one hand, whether they serve to let you play (UruExplorer), merely provide limited pieces of information (WhoM), or let you participate in a limited sense (libpurple plug-in); on the other hand, whether an actual person logs in (all three) or a bot (OHBot, etc.). WhoM uses the same account as the regular UruExplorer client. I would expect a bot to eventually use its own account.

OHB · **Joined:** Wed Feb 10, 2010 12:28 am **Posts:** 1247

chucker wrote:

Christian Walther wrote:

Are these categories even well-defined? I guess WhoM is a client (since it makes its own connection to the server) and OHBot is an addon (since it works through Cyan’s official client), but once we can build our own game clients based on Cyan’s, all kinds of in-between things become possible.

I'm not sure why you're muddling orthogonal facets of a client — on the one hand, whether they serve to let you play (UruExplorer), merely provide limited pieces of information (WhoM), or let you participate in a limited sense (libpurple plug-in); on the other hand, whether an actual person logs in (all three) or a bot (OHBot, etc.). WhoM uses the same account as the regular UruExplorer client. I would expect a bot to eventually use its own account.

Here's my PERSONAL feelings on this.

1. The back-end client-server communications are so perilous right now that 3rd party REPLACEMENT clients shouldn't be allowed (YET).

2. There should be hooks within the client to allow add-ons to easily do things.

3. There should be a central API to handle other stuff like WhoM.

JWPlatt · **Posted:** Sun Apr 04, 2010 6:57 pm

OHB wrote:

3. There should be a central API to handle other stuff like WhoM.

When you say "central," do you mean one server handling all shards, or one standard which all shards can implement?

chucker · **Posted:** Sun Apr 04, 2010 7:03 pm

I find it hard to see how an absolute "central" authority will work (or why anyone would want that) with an open-source model.

Teedyo · **Posted:** Sun Apr 04, 2010 7:50 pm

I'm going to guess that when OHB says central; that he really means 'common'. I think this makes sense in the WhoM case because it would allow a single(central?) web app to poll all known shards and create a single list of who's online where.

OHB · **Joined:** Wed Feb 10, 2010 12:28 am **Posts:** 1247

I'm gonna leave my comment as is and bow out at this point

chucker · **Posted:** Sun Apr 04, 2010 8:28 pm

Teedyo wrote:

I'm going to guess that when OHB says central; that he really means 'common'. I think this makes sense in the WhoM case because it would allow a single(central?) web app to poll all known shards and create a single list of who's online where.

Even if we were to accept that there's only one auth server, i.e. one central, "common" authority (which I think is unfeasible at least for development purposes — does anyone actually think that experimental Uru builds at Cyan connected to the public auth server? Kinda risky, no?), this would still be be quite difficult: each shard has its own KI numbers, so there's no common registry for what constitutes one and the same avatar.

One could of course go through the pains of having the user manually merge multiple avatars together and have them assert that they're one person, similar to what some IM clients let you do.

Teedyo · **Posted:** Mon Apr 05, 2010 3:53 am

Easy: Shard, Expl_name, KI_num. Every entry is unique.

Clarify. I don't think there needs be only one list. It's just that with a common API there can be... or there can be a dozen complete lists.

Quote:

I'm gonna leave my commend as is and bow out at this point

@OHB Of course, you are commendable.

OHB · **Joined:** Wed Feb 10, 2010 12:28 am **Posts:** 1247

Teedyo wrote:

Easy: Shard, Expl_name, KI_num. Every entry is unique.

Clarify. I don't think there needs be only one list. It's just that with a common API there can be... or there can be a dozen complete lists.

Quote:

I'm gonna leave my commend as is and bow out at this point

@OHB Of course, you are commendable.

Yes but /doh

Bots and other addons

Who is online