The server could also host the web front-end and manage users and their authentication.
It would also make changes to the DB through an API accessible from the front-end.
+calculations
The interfaces grabs information from the DB and shows it to the user.
How would the interface authenticate with the DB?
If the interface can directly change the DB (voting for example) you could use the login/password from the interface to make any changes you want.
I feel like all of this functionality - authentication, getting information and modification - should be in the libraries we provide to users, including authentication. I don't know too much about this, but it'd be kind of like a PHP session. When you authenticate, you get a "ticket" which is yours alone, and valid while you keep using it. It times out after a little bit, or you store that in a cookie-like situation. Encrypted communications should ensure nobody else gets that ticket.
Having a web frontend makes everybody HAVE to use that particular webserver. I don't see why this can't be handled by whatever interface you decide to use
If you're using a web interface, you use the web login. If you're using it on your smartphone, you login from your smartphone's application.
I have no experience at all with server-client relations and all of that stuff, but I think computation should not be done by the server but the client. When more and more people start accessing the server you would probably get serious performance problems pretty soon.
You can do client-side computation for things like, "how do I display the debate", but for calculating debate outcomes you need something dedicated. Like BoboJack said, different clients have different architectures, and they give different results. Interfaces are also proned to be hacked (especially if they're open-source...), so that you can't really trust them. At the
very least, you'd need server-side verification of the the results, which is actually faster than calculating everything, so that is an option.
It all amounts to the underlying infrastructure. A debate for 3 people can run everything on a mobile phone. A debate on Bay12 needs more infrastructure. It's up to whoever is hosting to handle that.
The algorithm we have right now does not handle incremental changes. There's some minor optimisations you can do, but we still need to recompute almost everything whenever there's an update (including a single vote). This is a limitation that it would be amazing to get over, so I can put up a description of the algorithm at some point for you to review. The idea's actually pretty simple. You can modify the algorithm, but you need to prove that it'll still do what we want.
I think at the moment we can handle a few thousand arguments in a couple of seconds. Like I've told those I've talked to, we've had someone working on optimising these things for a few months, and this is what he came up with, so I believe at the very least it's a good starting point. Eventually people should be able to use higher-end machines with multiple cores (the algorithm is
highly parallelizable), which should make things better.
Remember that this is intended for more than just debates- I also want this to be useful for things like what we're doing right now - planning projects, discussing ideas, etc. Really, I'd like to call it dscourse, but someone already made off with that name.
I was using debate in the wider sense - any discussion where points are made and argued over. For instance, I'd say we are engaging in a nice debate about how to organise an application. I suppose people might have some fairly strict notion of what a debate is. We should definitely include the idea that it's "social", because of the voting and the fact that outcomes depend on the context in which discussions are carried over.
Funny how coming up with a name is usually one of the hardest parts
Gimmie a few minutes and I'll put up a little infrastructure diagram of how I think most interactions can go.