It is currently Mon Nov 11, 2019 11:23 pm

All times are UTC




Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 12 posts ] 
Author Message
PostPosted: Mon Mar 01, 2010 10:36 pm 
Offline

Joined: Mon Mar 01, 2010 8:37 pm
Posts: 3
Background:
So as I am reading though this forum, there seems to be a very common theme: People worrying about URU splitting up into a huge number of different distributions, and it turning into a massive "second life" due to the tendency for the few weird ages that will most likely be made. I've compiled a few of my opinions and suggestions on the matter in this post. Before you read them, please read this short background.

Keep in mind, I have only played the first myst and URU, I've yet to get Riven to work, and I've only played part way through Myst III. I didn't know IV and V existed until yesterday (from this posts time). Sorry if my suggestions create continuality issues.

Please read this entire post before commenting, as I've had to revise it many times and put a lot of thought into it. Some portions may have incomplete ideas, I did not mean for this to happen... but if you read the entire post, it should also all become clear. Also, please understand that some ideas may have already been suggested in other posts (reading everything would be time consuming), so consider this one a repository if you see these re-posts. (( )) will be used to dictate out of character chat where necessary to make sure the messages are clear, explaining why it would be done this way, and to solve any issues or prevent misinterpretations. [[ ]] would be used to dictate when text is meant to be read from a role playing perspective, where necessary.I've had my fair share of managing projects, and I've even done an open source project too.

Anyways, here are my opinions and suggestions on the matter:

A New Beginning.
I agree with RAWA's rules about continuality for OFFICIAL ages, and required approvals before they can be added to the Cyan servers. This keeps a core focus in URU. However, this severely limits creativity too. So, here is my proposition for this:

Some explorers have attempted to write new ages, where some were dangerous and threatening to vistors. The DRC initially forbade this practice, until they discovered yet another secret. It seems Yeesha foresaw this problem, and wrote an age just for this. ((we will call this age "A Short Story" for lack of a better name at the moment)). This age will teach explorers how new Writers and Maintainers could SAFELY store their ages for revising and maintainance: Creating their own private city neighborhood ages. She explained that they could be kept private, shared with a friend, or shared with the world through the nexus ((this would make linking to people's neighborhoods more useful)). There, they can display their ((unoffical and unapproved fan made)) ages.

The DRC greatly approves of this, as it will encourage the rebirth of D'ni by bringing back the lost art, and at the same time, this will discourage inexperienced visitors from accidentally linking to experimental ages without invites, and also reinforces their understanding that anything they see or hear in these new explorer created ages may not have actually been a part of D'ni history ((eliminating continuality issues)). They are, rather are a fantasy caused by the rebirth of the lost arts, and skilled writers can use illusion to make things seem real ((this resolves continuality issues arising from people writing ages outside of common D'ni ability, and can be further be quelled by stressing a reference to Ahnonay, and how Kadish made it seem like the age was controlling time)).

Explorers who wish to debut their neighborhoods on the nexus must go through a DRC approval process through the new Guild of Maintainers ((reasons and process is described throughout the Real Life Side section)).

Now on the real life side:

Legal Issues:
When a person links to a private neighborhood, instruct them they are leaving the Cyan servers (explained later), and they are doing so at their own risk. Opinions, art, and ages found there are NOT their responsibility, and that explorers venture there at their own risks. Also, once again, remind them the content found is not officialy part of URU Canon.

Fan Ages and Neighborhoods:
Allowing unapproved fan created ages on the Cyan servers would be silly. It's reckless and dangerous. Next thing you know, you will have some adult themed D'ni strip club age (you KNOW its going to happen) and everyone will be visiting it; bringing all that foul language and other trash back to the public city places and turning URU into a pile of crap. So, in order for these people's neighborhoods to be displayed publically, first the writer must have written at least one complete age that is actually Myst/URU oriented, before they can make their neighborhood public for everyone to visit (they can invite people and allow buddy access however regardless if it's public). Any ages which are not Myst/URU oriented cannot be displayed in the public neighborhood or their neighborhood will be striked from the nexus by the DRC.

For consistancy reasons and to help avoid confusion, the word "shard" should become synonymous for these player neighborhood instances in which custom ages are being hosted.

Fan ages do not all have to be displayed in the neighborhood. The player may embed ages within ages as they wish (Eder Gira and Eder Kemo come to mind). They can also choose to allow or deny certain books and stones from being "bookmarked," all of which will be described in more detail later in this post.

Servers and bandwidth:
There is always the issue of bandwidth. Bandwidth is very expensive. I wouldn't ask Cyan to host fan created ages unless it's integrated into the actual game. Therefore, there is a second requirement to create a public neighborhood: the owner must host a shard from which their ages will be distributed from and linked to. This server is where the ages and intereactions will be coordinated from, leaving the Cyan servers to focus on authentication and the main storyline.

Authentication issues:
People can either directly connect to the fan neighborhoods by putting in the DNS or IP of the shard, or by linking through the official nexus. Under no circumstance should Myst Online usernames or passwords EVER be sent to a shard! To identify a person and ensure they are who they say they are, instead, the client will give the shard their User ID and a Private Key. The shard will then attempt to connect to the Cyan authentication servers, provide the private key, and if successful, download character data.

If the key is leaked, a person merely requests that a new key is generated.

Cyan Auth Servers offline?
It is not a requirement to be authed by the Cyan Auth servers. Here are the following modes:
  • Shard owners can decide to use their own username and password system (they cannot be listed as a public neighborhood using this method). When linking, the user will be provided with a user:pw login window, complete with an auto-login checkbox. If they do not have an account, they can click a register button, and either fill in information in game, or be provided with a hyperlink to a web page where they can register. Users will also be warned they are passing authentication data to a third party, so they should NOT use their Myst Online login or password.
  • Use a fallback method by accessing stored authentication data if the Cyan Auth Servers are offline, and the user had played previously.
  • Allow the client to supply data about the player's character. Note that this is only when joining the shard. There is no reason important enough as to allow a third party to have any write access to the cyan character database. (i briefly touch on third party character databases in "Multiplayer Ages without hosts" to account for third party character tracking)


In the cases where the Cyan Auth server is offline, the KI will specify so, reminding the player that the Auth Servers are currently inaccessable from the shard they are playing on, as to prevent people from taking advantage of the offline status and trying to impersonate others. As a roleplay sense, it could be a blinking cursor of the Great Zero, stating that the KI cannot establish a link, and are therefore currently confined to their Shard.

How would they be "bookmarked" like in the Relto Shelf?
Yeesha placed two things in her Short Story age: a KI dispenser, and a Relto page. The dispenser gives explorers the ability to access the Nexus's new functionality. The new Relto page will allow other players to link others and themselves directly to their nexus, allowing them to access the hidden bookshelf described below (and allows them a method of accessing the nexus bookshelf if the main Cyan servers are down). Note players visiting other's nexus cannot use the nexus terminal, as it would not respond to their KI.

When a player is in the Nexus, it will have a link in the display screen to the secret panel which has the Guild of Maintainers Symbol. When the player selects this link, the nexus screen will display only the shards in which they visited or were invited to, AND which the owner is allowing to be displayed in the nexus (some owners might prefer people visiting their neighborhoods or only allowing invites in order to access their ages). When the player selects one of the shards, they will get two buttons: Link to shard, or display bookmarks. Linking to the shard is like being invited or finding it in the public list; linking will send you to their neighborhood. If they chose display bookmarks, a bunch of mechanical whirlygigs will happen, opening hidden booksheves in the nexus. These booksheves are much like the Relto bookshelf, keeping track of a player's progress through that shard's ages.

Note that pressing EITHER of those buttons will display the legal warning, as in order for this to function properly, control must then be passed to the shard (otherwise where would bookmarks be saved? Would be a lot of stress on Cyan's database if they were saved there)

If the shard is down, the player will be notified and an error animation will display on the nexus panel.

Alternative to above:
Place another special book slot in Relto, where it links them to a grand Relto Library. When they link in, they will be standing on a platform in a very dark library (they can only make out the faint silouettes of the shelves and the millions of books on them). They get a KI slot where it does the same thing as the nexus, displaying neighborhood/shards. The relto page will instead link to this "Great Realto Library." When the player selects "display bookmarks" it will the legal warning, and if accepted, they will have an animation where they are being taken to the appropriate row and bookshelf while their client authenticates to the shard. (reminds me of that underground train thing in Myst). They can then select the appropriate books and allow certain ones to be shared if they desire.

If they cannot connect to the shard, the platform will stop and display an error, along with a pop-up just as in the suggested nexus changes.

Custom URU Clients:
As long as client's agree on certain communication standards, there shouldn't be an issue with using a custom URU client on the official servers or the shards. For shards and ages which require more than just the standards, clients should be able to support scripts which change the way the clients communicate. CRC and hash checking can be built into the client to ensure the clients are using compatible builds. The checks are ONLY for compatibility checking.

This isn't a shooter or anything, so cheating should not be a concern. However, in any timed trial games, custom clients should have the ability to fall back on official builds only, as this is the only area I can think of in which cheating would be a concern.

Offline Mode
Players should be able to download stand-alone plugins of these ages at the creators choosing. This allows those people to play on metered internet, or if the creators cannot host those ages in a multiplayer neighborhood.

Multiplayer Ages without hosts
For those people who make group ages, but cannot host a neighborhood, they could ask another person if they would be able to host the age. Nothing dictates here that multiple people cannot host an age, but progress cannot be tracked unless these shards allow character data to be shared with each other, or store said data in a shared database (the age can dictate what shard or database the character data should be stored in, but the shard itself can override these settings on a per-age basis). Unfortunately, this all introduces a very technical setup which can't really be explained to players in a role-play sense when they ask about why their age in one neighborhood isn't being saved to another, but this might be something that should be explained by a DRC book or by the guild of greeters. This shouldn't be a problem for the reputable neighborhoods, and those smaller neighborhoods which DO override these settings will probably have people visiting who know and understand this already.

If the shard owner wishes for simplicity reasons, the player's client can instruct the shard on how far along the player is in any particular age. This can cause a lot of cheating, but seriously, this isn't a shooter, so why should you care? :)

Private shared ages
If individuals wish to make a private age as a simple click-and-go, the URU client will have listen server capability built in. When someone invites a friend to an age they are testing, the clients will directly connect (don't forget the legal warning!) and the inviter will be the host.

Unfortunately, this setup would not be designed to hold multiple instances of an age (meaning Bill and Jill cannot both save progress of the same age), so either Bill or Jill need to provide a download for the other to get if they want to save their progress through the age. In fact, I cannot think of a reason why a listen server setup should ever save someone elses progress.

Credits for the ages
Credits for age creation can go onto a panel at the beginning/end of the age, or somewhere in the linking book (A credits page in the back of the book?)

Why all the effort for custom ages?...
Why? Three words: Tsogal and Delin. When I first arrived in the Guild of Greeters, Tsogal was all the rage. I heard a lot of talk about it. I got the impression that it was this epic multiplayer age with crazy puzzles requiring coordination with many people. When I did my first run, I was kind of disappointed...

Now, imagine creating ages where that was just the first part..... but where will you find the people to run it with you? You can post to all the forums and mailing lists that you want, setting up events and synchronizing timezones is as big of a challenge as the ages themselves could be. People not making their promises, or unexpected events coming up... eventually people will give up and stop trying.

However, this system would be quite easy to fill replacements, just like in Tsogal and Delin. Just have someone link back to the greeters bevin and recruit some more.

There is also a second part of this: The more effort required to obtain ages, the less willing people would be to get them. By providing an automated distribution method, simply by linking to the neighborhood and/or age, you eliminate two major factors: Lazyness and technical illiteracy.

Finally, it allows large congregation hubs as MOUL does right now. Overhearing conversations as you run past, talking about the age that someone just ran and how much fun it is, will peak curiosity (as it did with me and Tsogal). This translates to a wider audience exposure, and much more easily keeps interest in the game since it requires very little effort to explore new places. This keeps MOUL alive. You just can't get this on a forum unless people stumble across your topics, because people have to be searching for those topics or something related.

On a less obvious note, this also encourages the open source URU builds to keep in touch with the Cyan's version. It keeps a focus on the Cyan build, and many client's won't deviate too much from it. Client programmers can still do as they please, this by no means prevents them from writing a whole new client for their own servers. Without a focal point, open source systems tend to drift apart, eventually developing into entirely new systems.

As an example, a couple of focal points in Linux are the kernel and the Free Software Foundation philosophy. Everyone makes their own distributions, and nothing is stopping them from making complete rewrites. But thanks to the kernel and the FSF, it helps to remind people when it's still linux, and when it is it's own entirely new operating system altogether. It gives them a point of reference, something consistent they can base on. This creates a comradeship among the distros, and even though some have rivalries, if and when a change to the kernel would benefit ALL of them, they tend to all contribute.

Credits:
I will reference posts that I've taken suggestions or ideas from. If you aren't on this list and feel you should, PM me.
http://mystonline.com/forums/viewtopic.php?t=20070 Had some interesting concerns, many should be resolved by everything I've talked about above.

If you like this idea, or don't, please leave feedback, and come up with any other issues that may arise from this build.

Revision History
03/02/10: 1.2.1: Revised Custom URU Client section so it is more clear what the goal is.
03/02/10: 1.2: Added a "Why" section.
03/01/10: 1.1: Clarified the username:pw shard section slightly.
03/01/10: 1.1: Added information on how to handle single or multi-player ages, and simple listen server functionality.
03/01/10: 1.0.1: Minor edits for formatting, clarified some statements. Added this version section to help keep track of edits.
03/01/10: 1.0: First Post.

_________________
Signature.


Last edited by Anticept on Tue Mar 02, 2010 10:07 pm, edited 9 times in total.

Top
 Profile  
Reply with quote  
PostPosted: Tue Mar 02, 2010 2:11 am 
Offline

Joined: Fri Feb 19, 2010 5:04 pm
Posts: 115
Location: England
Anticept wrote:
Legal Issues:
When a person links to a private neighborhood, instruct them they are leaving the Cyan servers (explained later), and they are doing so at their own risk.

I'm not entirely sure that Cyan would even go for this. If the starting point is Cyan's server (or Cyan's age on a third-party server), it doesn't matter if the ultimate destination is seven degrees of Kevin Bacon away, it can still be (mis)construed as Cyan's game.

Anything beyond fan-run servers hosting entirely fan-created content is dependent upon what restrictions Cyan imposes upon their content. If they want, they can require approval for any shard using their content (ages, textures, models, D'ni storyline) or linked (directly or indirectly) from their servers. That would result in two distinct ecosystems: one where everything is controlled by Cyan and another where nothing of Cyan's exists beyond the open-source software.

Anticept wrote:
Authentication issues:
People can either directly connect to the fan neighborhoods by putting in the DNS or IP of the shard, or by linking through the official nexus. Under no circumstance should Myst Online usernames or passwords EVER be sent to a shard! To identify a person and ensure they are who they say they are, instead, the client will give the shard their User ID and a Public Key. The shard will then attempt to connect to the Cyan authentication servers, provide the public key, and if successful, download character data.

That's one model. Another (as you note below) is that a shard has its own user list. MOUL currently gives out logins to anyone who asks for one. Fan-run shards may be more restrictive; some will need to be more restrictive (particularly if they're running on someone's home PC). Clicking on a linking book to such a shard would basically mean: log off then log on to a different server, possibly with a request to start at a specific link point. The client would ideally need to keep a list of server:username:password records so that the user doesn't have to manually log in whenever they move to a different shard.

Anticept wrote:
Cyan Auth Servers offline?
It is not a requirement to be authed by the Cyan Auth servers. Here are the following modes:
  • Shard owners can decide to use their own username and password system (they cannot be listed as a public neighborhood using this method). Users will also be warned they are passing authentication data to a third party, so they should NOT use their Myst Online login or password.

I think it would be easier to assume/require that the user already has an account on the destination shard. At the point the linking book is opened, the client would check whether the user has an account on the shard (and possibly that the shard is up and running), and display "snow" if the user lacks an account or the shard is down.

Anticept wrote:
  • Allow the client to supply data about the player's character.

This needs to be designed in such a way that shards can handle unknown details. E.g. different shards may have different sets of clothing available. Individual shards would probably track the avatar's inventory themselves, so if you pick up a clothing item on one shard you can't necessarily expect to be able to wear it on a shard where you don't possess that item.

There's also the issue of which avatar names are in use on a particular shard. It should probably be considered polite not to use an avatar name which is already in use by someone else on Cyan's shard.

Anticept wrote:
Custom URU Clients:
Unless it's cosmetic or does minor changes like bugfixes, there shouldn't be an issue with using a custom URU client on the official servers.

MAJOR changes to URU clients, such that may be required for certain custom ages, is something that should probably be left with an offline or shard-only mode. The more flexibility allowed on a client, the more easily exploits which can ruin the game for others can/will be found.

The server cannot know, let alone control which client is used. A client may choose to identify itself as a specific builds in order to protect the user from incompatibilities. But if someone modifies the client with the specific intention of cheating, it's unlikely they'll go to the trouble of informing the server of this fact.

Anticept wrote:
This isn't a shooter or anything, so cheating should not be a concern. However, in any timed trial games, custom clients should have the ability to fall back on official builds only, as this is the only area I can think of in which cheating would be a concern.

If users want to cheat, you either find some way of preventing it within the server, or you just accept it. Client-side anti-cheating techniques require a vast amount of effort, aren't particularly effective, and have a high risk of collateral damage (you typically have to put some hooks fairly deep into the OS).

Realistically, we should just ignore the possibility unless it actually starts to matter.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Tue Mar 02, 2010 4:45 am 
Offline
Obduction Backer

Joined: Sat May 05, 2007 7:58 pm
Posts: 81
Location: Woodstock, GA
Chances are, there will end up being two ways to access FCC.

First, Cyan-Approved content will be inserted directly into the game. This would probably be done through the nexus (or possibly a second Fan-Content Nexus). This is the best way I see this working.

Second, Non-Cyan-Approved content will have to be accessed through "hacked" clients that can connect to an alternate server.

_________________
Ahda Mor #55503 | Greeter Ahda #1803579


Top
 Profile  
Reply with quote  
PostPosted: Tue Mar 02, 2010 7:51 am 
Offline

Joined: Mon Mar 01, 2010 8:37 pm
Posts: 3
Keikoku wrote:
Anticept wrote:
Legal Issues:
When a person links to a private neighborhood, instruct them they are leaving the Cyan servers (explained later), and they are doing so at their own risk.

I'm not entirely sure that Cyan would even go for this. If the starting point is Cyan's server (or Cyan's age on a third-party server), it doesn't matter if the ultimate destination is seven degrees of Kevin Bacon away, it can still be (mis)construed as Cyan's game.


These people who misconstrue it would have no consequence on the Canon of the game. The vast majority of people who would host the custom content, and visit it, would understand this fact. The few who do not... /shrug.

Keikoku wrote:
Anything beyond fan-run servers hosting entirely fan-created content is dependent upon what restrictions Cyan imposes upon their content. If they want, they can require approval for any shard using their content (ages, textures, models, D'ni storyline) or linked (directly or indirectly) from their servers. That would result in two distinct ecosystems: one where everything is controlled by Cyan and another where nothing of Cyan's exists beyond the open-source software.

Not really sure how this relates to the topic, but point taken :)

Keikoku wrote:
Anticept wrote:
Authentication issues:
People can either directly connect to the fan neighborhoods by putting in the DNS or IP of the shard, or by linking through the official nexus. Under no circumstance should Myst Online usernames or passwords EVER be sent to a shard! To identify a person and ensure they are who they say they are, instead, the client will give the shard their User ID and a Public Key. The shard will then attempt to connect to the Cyan authentication servers, provide the public key, and if successful, download character data.

That's one model. Another (as you note below) is that a shard has its own user list. MOUL currently gives out logins to anyone who asks for one. Fan-run shards may be more restrictive; some will need to be more restrictive (particularly if they're running on someone's home PC). Clicking on a linking book to such a shard would basically mean: log off then log on to a different server, possibly with a request to start at a specific link point. The client would ideally need to keep a list of server:username:password records so that the user doesn't have to manually log in whenever they move to a different shard.

Those which use the authentication models I mentioned will indeed be kept on the client. As said however, a user should not ever have to provide their MOUL login, and should be reminded of this fact if they are prompted.

Keikoku wrote:
Anticept wrote:
Cyan Auth Servers offline?
It is not a requirement to be authed by the Cyan Auth servers. Here are the following modes:
  • Shard owners can decide to use their own username and password system (they cannot be listed as a public neighborhood using this method). Users will also be warned they are passing authentication data to a third party, so they should NOT use their Myst Online login or password.

I think it would be easier to assume/require that the user already has an account on the destination shard. At the point the linking book is opened, the client would check whether the user has an account on the shard (and possibly that the shard is up and running), and display "snow" if the user lacks an account or the shard is down.

I didn't make this part very clear. I was assuming that when a person goes to link to a user:pw shard, they are provided popup which asks for a user:pw combo, or provided a registration window/registration link. The client also has the option to save and auto-login. Updated my post accordingly.

Keikoku wrote:
Anticept wrote:
  • Allow the client to supply data about the player's character.

This needs to be designed in such a way that shards can handle unknown details. E.g. different shards may have different sets of clothing available. Individual shards would probably track the avatar's inventory themselves, so if you pick up a clothing item on one shard you can't necessarily expect to be able to wear it on a shard where you don't possess that item.


Custom shard items will not carry over. This system is to dictate information when coming TO the shard. There is no reason for information to be sent back to the Cyan servers unless the client is rejoining the primary shard. Updated my post to clarify this.

Keikoku wrote:
There's also the issue of which avatar names are in use on a particular shard. It should probably be considered polite not to use an avatar name which is already in use by someone else on Cyan's shard.

This was covered in another section. To clarify: you can't prevent UN:PW shards from doing this, however those maintaining an API link (the userID key method) prevents this from occurring.

Anticept wrote:
Custom URU Clients:
Unless it's cosmetic or does minor changes like bugfixes, there shouldn't be an issue with using a custom URU client on the official servers.

MAJOR changes to URU clients, such that may be required for certain custom ages, is something that should probably be left with an offline or shard-only mode. The more flexibility allowed on a client, the more easily exploits which can ruin the game for others can/will be found.

The server cannot know, let alone control which client is used. A client may choose to identify itself as a specific builds in order to protect the user from incompatibilities. But if someone modifies the client with the specific intention of cheating, it's unlikely they'll go to the trouble of informing the server of this fact.[/quote]
CRC and hash checking would be built into the client. Legitimate clients would notify servers accordingly of any changed libraries.

I really don't want to get too deep into this portion of the client, this could generate some touchy subjects.

_________________
Signature.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Tue Mar 02, 2010 11:17 am 
Offline
Obduction Backer

Joined: Sat May 05, 2007 7:58 pm
Posts: 81
Location: Woodstock, GA
I wonder if all this authentication could be handled in a way similar to "facebook connect" (or openID).

You'd have the one login through cyan's server, and any shards could piggyback on that...I don't know what kind of structure needs to be in place to offer that kind of system though...just an idea. I mean, chances are, if anyone wants to play this game, regardless of which shard they choose, they are going to have an account with the official server.

_________________
Ahda Mor #55503 | Greeter Ahda #1803579


Top
 Profile  
Reply with quote  
PostPosted: Tue Mar 02, 2010 4:20 pm 
Offline

Joined: Fri Feb 19, 2010 5:04 pm
Posts: 115
Location: England
Anticept wrote:
Custom shard items will not carry over. This system is to dictate information when coming TO the shard. There is no reason for information to be sent back to the Cyan servers unless the client is rejoining the primary shard. Updated my post to clarify this.

There seems to be an assumption that Cyan will continue to run servers for the foreseeable future. I don't know how safe that assumption is. We should consider the case where there is no "central" or "primary" shard.

Anticept wrote:
keikoku wrote:
The server cannot know, let alone control which client is used. A client may choose to identify itself as a specific builds in order to protect the user from incompatibilities. But if someone modifies the client with the specific intention of cheating, it's unlikely they'll go to the trouble of informing the server of this fact.

CRC and hash checking would be built into the client. Legitimate clients would notify servers accordingly of any changed libraries.

And illegitimate clients will simply provide the hashes corresponding to a legitimate client.

If you want to perform validation on the client, you need some code on the client which is protected against tampering by the owner of the system running the client. The techniques required to achieve thisare likely to have negative side effects, e.g. anti-virus software is likely to flag it as malware, it represents a serious risk to system stability and/or security (typically, some of the code has to run as a device driver, and any bug in a device driver represents a critical security risk), the game can't be run under a limited (non-admin) account, etc.


Top
 Profile  
Reply with quote  
PostPosted: Tue Mar 02, 2010 9:50 pm 
Offline

Joined: Mon Mar 01, 2010 8:37 pm
Posts: 3
adrianbrooks wrote:
I wonder if all this authentication could be handled in a way similar to "facebook connect" (or openID).

You'd have the one login through cyan's server, and any shards could piggyback on that...I don't know what kind of structure needs to be in place to offer that kind of system though...just an idea. I mean, chances are, if anyone wants to play this game, regardless of which shard they choose, they are going to have an account with the official server.


This is what a variation on the key cryptography can do. It's not as decentralized as OpenID as it still relies on the Cyan servers, but it does provide what would be needed. Anyone needing access to character data provides a userid and the private key given by the client. If this key is leaked, the person can just generate a new key, and the client will download the new private key to be provided to shards.

Keikoku wrote:
Anticept wrote:
Custom shard items will not carry over. This system is to dictate information when coming TO the shard. There is no reason for information to be sent back to the Cyan servers unless the client is rejoining the primary shard. Updated my post to clarify this.

There seems to be an assumption that Cyan will continue to run servers for the foreseeable future. I don't know how safe that assumption is. We should consider the case where there is no "central" or "primary" shard.


This is why these settings can be overridden on a shard by shard basis. It's open source, so if someone makes a new central server, it's quite easy to push an update.

Anticept wrote:
keikoku wrote:
The server cannot know, let alone control which client is used. A client may choose to identify itself as a specific builds in order to protect the user from incompatibilities. But if someone modifies the client with the specific intention of cheating, it's unlikely they'll go to the trouble of informing the server of this fact.
CRC and hash checking would be built into the client. Legitimate clients would notify servers accordingly of any changed libraries.

And illegitimate clients will simply provide the hashes corresponding to a legitimate client.

If you want to perform validation on the client, you need some code on the client which is protected against tampering by the owner of the system running the client. The techniques required to achieve thisare likely to have negative side effects, e.g. anti-virus software is likely to flag it as malware, it represents a serious risk to system stability and/or security (typically, some of the code has to run as a device driver, and any bug in a device driver represents a critical security risk), the game can't be run under a limited (non-admin) account, etc.


You misunderstand, that's not the point of these checks. Again, I have zero concerns about cheaters in URU. This is to ensure compatibility with custom content on a shard, to prevent as many errors as possible while playing. Less technical intervention by the players ensures more acceptance. I've edited the Custom URU client section so that it's much more clear.

_________________
Signature.


Top
 Profile  
Reply with quote  
PostPosted: Thu Mar 04, 2010 12:19 am 
Offline

Joined: Fri Feb 19, 2010 5:04 pm
Posts: 115
Location: England
Anticept wrote:
Keikoku wrote:
Anticept wrote:
Custom shard items will not carry over. This system is to dictate information when coming TO the shard. There is no reason for information to be sent back to the Cyan servers unless the client is rejoining the primary shard. Updated my post to clarify this.

There seems to be an assumption that Cyan will continue to run servers for the foreseeable future. I don't know how safe that assumption is. We should consider the case where there is no "central" or "primary" shard.

This is why these settings can be overridden on a shard by shard basis. It's open source, so if someone makes a new central server, it's quite easy to push an update.

That still relies upon a consensus of which server is the "central" server.

I think that initially it makes more sense to simply not bother trying to carry any state between shards. On joining a shard, an avatar's state will be whatever it was when the avatar left the shard. The next step would be to allow the client to specify a preferred state which is adjusted according to what is acceptable to that shard.

Most of the avatar state is so insignificant that it probably isn't worth the effort of trying to design mechanisms to "securely" transfer it between shards. Either everything is stored on the shard, or the shard takes the client's claims at face value. It's not like a conventional MMORPG where there is significant "value" in an avatars state (possessions and experience). Allowing state transfer is something which is probably best left until there's a use-case which justifies the effort.

Anticept wrote:
You misunderstand, that's not the point of these checks. Again, I have zero concerns about cheaters in URU. This is to ensure compatibility with custom content on a shard, to prevent as many errors as possible while playing. Less technical intervention by the players ensures more acceptance. I've edited the Custom URU client section so that it's much more clear.

Okay. In that case, I think that hashes (or similar) are the wrong way to go. It would be better to have a registry of specific "features" so that each side (client and server) can inform the other of which features they understand. The client wouldn't try to use features which the server doesn't support, wouldn't try to connect to servers which state that they need a feature which the client doesn't support, and would honour any requests from the server to enable or disable specific features (although it's up to the server to kick/ban users who actually violate such policies).

Identifying specific clients can work where the number of distinct clients and versions is small, but doesn't really work with an open-source development model.

The main problem with attempting to identify specific clients is that the server needs exhaustive knowledge of all available clients, and would presumably reject unknown clients even if they supported all of the necessary features. This would be problematic for clients which are under development, as the hashes would change with even the most trivial change. They would even change if the user compiled an unmodified client themselves with a different compiler or different compilation options (they may even change according to the compilation date or the name of the machine on which compilation occurred). If you use hashes (or even client name and version), developers will have little choice but to add support for "impersonation" just so that they (and other users) can test their as-yet-unknown client.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Fri Mar 19, 2010 4:25 am 
Offline
Obduction Backer

Joined: Tue Aug 22, 2006 4:36 am
Posts: 763
I just want to know, once a fan written age is available (approved, vetted, etc), then where/how will the players access the new age? Is there going to be more books in the library or the museum? Or do we have to play them offline, unconnected to Uru Live?

_________________
*Uru is us*
New Ki 00158646
Original KI number 00364222


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Fri Mar 19, 2010 5:14 am 
Offline
Obduction Backer

Joined: Tue May 09, 2006 4:33 pm
Posts: 878
Location: Jurupa Valley, CA USA
Todoni wrote:
I just want to know, once a fan written age is available (approved, vetted, etc), then where/how will the players access the new age? Is there going to be more books in the library or the museum? Or do we have to play them offline, unconnected to Uru Live?


To be determined. That's several miles down a road we've only taken a couple of steps on.

_________________
MOULa KI #32712
MOULa KI #23298
MOUL KI #35129
D'mala KI #74265
Gehn KI #10113


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Fri Mar 19, 2010 6:21 am 
Offline

Joined: Thu May 11, 2006 5:22 pm
Posts: 1814
Location: California
Todoni wrote:
I just want to know, once a fan written age is available (approved, vetted, etc), then where/how will the players access the new age? Is there going to be more books in the library or the museum? Or do we have to play them offline, unconnected to Uru Live?

Deledrius is right we really don't know. When Cyan tells us what we can and cannot change in their content we can decide. If they allow us to change Relto then we can put new books on the selves. If the let us change the nexus, we can add ages there.

All we know is there has to be something we can change to get to at least one new fan age, that could be the nexus for all other fan ages. But what that will be is speculation.

MOUL is a preloaded game, everything downloads or updates then the game starts. So, we expect new ages to be added to the server. At logon any new age would download using the current updater built into Uru. It might not be much work to give you the option to download a new age or not. May be something like the Blue Mars startup interface does now.

Once open source is out and going we might change how new ages are delivered.

_________________
Nalates - GoC - 418 - MOULa I: Nal KI#00 083 543, MOULa II: KI#00 583 875Nalates 111451 - Second Life: Nalates Urriah
Guild of Cartographers Image


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Wed Mar 24, 2010 2:29 am 
Offline
Obduction Backer

Joined: Tue Aug 22, 2006 4:36 am
Posts: 763
WoW! Awesome ideas. Thank you for the info, too, on how we might access any new ages. Its going to be so hard to be patient, and see how it will be done!

I wish we could have not just different posts, but different topic areas, for things like suggestions for new ages, things pertaining to mechanical issues (like shards and how/where we access a new age), etc. I would not be surprised if the suggestions forum was much larger than the "how to" forum. :wink:
It is to be expected, though, because for now all we can do is think up ideas.
Lets make a huge stack of ideas! Then when we learn more on the "how to make this happen" side of things, it might be easier to see which ideas are do-able,and which ones will need to wait until a newer type of computer is invented. :)

_________________
*Uru is us*
New Ki 00158646
Original KI number 00364222


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 12 posts ] 

All times are UTC


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
Jump to: