Proposal VE WalletIntroductionCurrently there are several applications that have been written by members of the Vast Empire that allow access to the database. Those applications are allowed access to the database because they have been written by trusted developers. This means of development cannot continue because the list of trusted developers has decreased dramatically over the years. In order to provide more applications that can be used by members of the Vast Empire, an ability to access limited parts of the database must be created.
RequirementsIn order for this to be a valuable component of the Vast Empire architecture, there must be several things that can be done on a wallet.
1. The wallet must allow for an identity to be provided and logged into from an external connection. This access will provide a session ID that can be used to access various parts of the wallet. Session id should be something along the lines of a hash made up of the website and the user name and password.
2. The wallet must allow for IC's to be transferred between a FGB account and a wallet.
3. The wallet must allow for IC's to be transferred between wallets.
4. The wallet must be persistent for as long as the user wants his wallet to exist. Sites must be able to rely on the session information returned by the wallet in order to link data to a user. This will allow databases to keep information and link them to users that are logged in.
a. The user must be able to delete the wallet whenever they feel it is necessary. This means that the session id must no longer provide access to the website.
VEEC Use CaseDoing this will allow more applications the ability to link into the VE profiles of users. This would allow applications like the VEEC website to provide a login that is similar to the one that is used to log into the VE website.
0: A user will visit the VEEC website.
1: User clicks on the log in link.
2: Web browser redirects the user to the VE.com/wallet website
3: Based on the website referrer the wallet code is able to determine if the user has linked to the requesting website.
3.1: If the user has a session stored off for this website, then a session id is returned to the requesting website
3.2: If the user does not have a session stored off for this website, then a login and password box should be displayed.
3.2.1: Upon successful login, the session information is stored in the wallet database and the session id is returned to the requesting website.
4: The website is able to request information based on the user session that is returned to the website using json or some similar technology.
I'm sure that when Kadann writes this, it'll be a lot more thought out than what I can do in 30 mins. But if members want new applications to play with, this is an important first step.
Just another pretty face....
Verastinian Republic - Almighty Dictator
"The difference between a hacker and consumer is a consumer says, 'I wish it would work this way.' A hacker says, 'I've got a screwdriver and a few minutes.' -- Rael Dornfest