Hi, I'm in the process of building a new open source (GPL) go server; OWGS, the "Open Web Go Server".

It's still in the early stages, but already allows one to register, log in, review games, play games against others online or against GTP bots, view archived games, collaboratively review games (to some extent), download game records, and chat.

It's all still quite ugly and preliminary but I thought posting here might bring in more interest and perhaps some developers. Right now, it's 100% written by myself. The codebase is Python/Django/MySQL on the server side, and Javascript/Eidogo on the client side. I use no browser plugins or proprietary nonsense, I'm going all HTML/JS/CSS for the front end. The backend server speaks a simple JSON-based network protocol, allowing creation of non-web-based front ends as well.

I just got the GTP bot stuff working last week, and now my interest is turning towards designing a really nice jQuery-based interface (the present interface is extremely minimal).

http://owgs.org
http://github.com/Tecuya/owgs
http://senseis.xmp.net/?OWGS

Please send me a message if you want to contribute, offer suggestions or criticism, send bug reports, etc.

I'm happy to provide high-res photos of shell stones (with different grain patterns).
But I'm not a Photoshop person, so you'll need a graphics designer to do the touch-up.

Cool. Right now I'm just using Eidogo for the board and I don't have any immediate plans on redoing the renderer, though I do eventually intend on doing some work on it so it will be variably sized.

It might be nice to have the pics just to incorporate in to the site design in an aesthetic / decoration capacity, if not for actual stones on a board.

For the actual stones on the board, of course.
And you can add a random rotation to each shell stone -- an upgrade over gGo/gIGo's fixed-rotation shell stones.

Is the protocol documented somewhere? (Even a pointer to the code that implements it would be nice.) I was working on a similar GPL's go server before health problems destroyed all my free time, but it would be nice to take a look at someone else's protocol to compare--if I ever get back on my feet and can restart my project, maybe I can make my server speak a compatible protocol and borrow the front-end code from OWGS.

When I clicked the activating link in my mail, the username field in the activation page was filled with my email, not my login. Don't know if it's a bug, or other (I use Chrome).

After having tested for a game (id=33), I think you're publicizing it a bit too early.

Here are the problems i encountered :
* the bot stopped playing on my last move
* I oppened a new tab to rejoin the game, my nickname was present twice in the list.
* The time went up, and after the five byo yomi periods, went to negative. It didn't tell me that the game was over.

The major bug being handling the win/loss by time.

A few minor quirks :
* the chat input isn't submitable by pressing enter
* there's another input box under the chat area, that doesn't do anything. I typed my text here first.

Good luck, I like the idea and I think it can be a really good server, so be careful not to lose users too fast!

The protocol is still pretty fluid, this is all very much in-progress still. Here's a super quick rundown. All commands are JSON arrays. Commands are delimited by newlines ("\r\n"), so any newlines in the command must be quoted. The number of parameters varies per command. If you sign up on the server, and enable "Debug" in your profile, then play a game against GNUGo, you'll see the raw protocol with time stamps in a textarea at the bottom of the screen. There's also a box you can use to submit raw JSON strings to the server to tinker around.

SESS - Client sends this to the server to identify itself by a session ID (for web clients that are already logged in)
AUTH - Client sends this along with username, password to identify itself (for non-web clients - currently just GTP bot)
ERROR - Server transmits this to inform the client that the previous command had an error. Argument is an error text string.
PCHT - "Part chat", send by a client to leave a chat channel, sent by the server to clients to inform them someone left the channel.
GAME - Client sends this to create a game, along with various game parameters (for non-web clients)
JOIN - Client sends this to join a game. Server sends this to notify others on the game that someone has joined.
CMNT - Client sends this to comment on a game, server sends it to send the comment to others
MOVE - Client sends this to make a move, server sends it to notify others of a move. In the client's request is a "parent node" that refers to the SGF node that the move is being made as a child of (supports making moves on variations etc)
SYNC - Server sends this if the client does something which indicates it is not synchronized with the server (like make an illegal move, attempt to NAVI when not allowed)
NODE - Server sends this to a client after they make a move to instruct the client to store a server-side node ID for the SGF node created by the previous move.
TIME - Server sends this to client with various time parameters to update the client's clock.
DEAD - Client sends this to mark stones dead, server sends it to relay client marking stones dead.
BEGN - Client sends this to accept an offer on a pending game, server sends it to relay the acceptance to other game participants.
OFFR - Client sends this to make an offer on a pending game, server sends it to relay the offer to others.
NAVI - Client sends this to seek to a specific node in the game tree, server sends it to relay the move to others.
UNDO - Client sends this to request an undo, server relays it to others
OKUN - Client sends this to accept an undo request, server relays it
NOUN - Client sends this to reject an undo request, server relays it
RSGN - Client sends this to resign a game, server relays it
SCOR - Client sends this to submit a final score, server relays it.. when both opponents send a matching SCOR the game ends and the submitted score is the final result
PART - Client sends this to join a game, server relays it to others
JCHT - Client sends this to join a chat, server relays it to others
CHAT - Client sends this to chat in a game, server relays it to others.

For the implementation see:
Server: http://github.com/Tecuya/owgs/blob/master/netserver.py
Client: http://github.com/Tecuya/owgs/blob/mast ... tClient.js

Thanks for the bug report, most of these were known issues, or unknown effects of known issues. I've updated my todo list.

Yeah, I was debating whether or not to let people check it out at all yet It's *definitely* early for mass publicizing, so I'm really not making much of an effort to get it out there right now. Besides making my SL entry, and posting here, I've made no attempts to publicize it... really I'm just posting it to get suggestions and maybe even some more developers.

I'm in the process right now of radically changing the web interface, so like practically everything besides the Eidogo widget is going to change very soon.. and I also have a lot of changes planned to Eidogo.

I figured that it can't hurt to get a few people playing with it now, because once I'm done it's going to be so awesome that people will forgive the fact that it was all screwed up before

For those keeping track, I just put up a new tabbed interface on http://www.owgs.org ..it's neat, check it out.

There are still plenty of bugs floating around, of course. I've spent a LOT of time on the tabbed interface stuff, and now that that's working I'm going to do a bit of a "feature freeze" and just stamp out bugs for a while.