Hi all,
nice to see some traffic here.
I too got some questions about secu-share/psyc I always
wanted to ask.
What I'm looking for is a replacement for some working code.
(Yeah, I know never touch a running system... But I view code
as a duty, not an asset. Whatever I can reuse would be a win.)
Could I do the following reasonably using PSC?
The code in question would be the communication protocol used for BALL.
http://ball.askemos.org/
(((BALL is in a way yet another "social network software", albeit
we seriously claim it being based on strange, 300 years old
ideas like democratic societies - much in contrast to the cloud-hosted
networks under control of their respective parent companies.
It also does not enforce any kind of application like news feeds etc.
onto it's users. Instead it just gives the user a choice of
programming languages to roll their own. All BALL does is kinda
web without servers. Applications run in the web caches instead.)))
That code layer I want to replace, does byzantine failure tolerance
and collaborative state transfer. This could be done atop of any
chat-alike protocol. It takes one channel (chat room) per state
machine to coordinate updates and distribute the current state in
case a node responsible to keep a state machine was offline during
some update.
Coordinating updates would be easy even using channels, which allow
only restricted character sets and small messages. It there are only
some hash codes and fixnums to be exchanged. However: there MUST
be some authentication (e.g., cryptographic signatures) for messages.
(Otherwise it would die fromthe first Sybill attack.)
State transfer however is different. Currently it's a custom protocol
over HTTPs similar to bitorrent. When, say a SQLite database is updated,
it's written blockwise, those blocks are transferred one-by-one. (We
never update the blocks; theirs hash forms a Merkele tree and blocks
are replaced upon update.) I don't see this being efficient in non-binary
encoding.
(((Side note: we have a few real users, who have no idea that there
is some distributed, fault tolerant database underneath their software.
They just expect "reasonable" performance when they post updates
under the expectation that "this is a web site". When replacing
parts, I should not break their experience.)))
On Oct 4 2013, Kẏra wrote:
On Tue, Sep 24, 2013 at 2:14 AM, carlo von lynX
<[email protected]
wrote:
On Tue, Sep 24, 2013 at 07:49:45AM +0200, carlo von lynX wrote:
> > when moving servers/identifiers? Those are two very important aspects
> > to the Tent protocol and, I would argue, any protocol for this
> > purpose.
>
> well, protocol designers have been very lazy in this respect.
> psyc at least has a _redirect message type, but we didn't really
> implement it. xmpp probably has some complicated xep by now.
> it used to not offer this feature for a decade.
actually i can dig a bit deeper into this: in order for accounts
to be transferable you need (1) a protocol to move the account
data, which is enough if only the two involved servers know about
it, and (2) a way to bounce a message and let any server in the
federation know, that your account has moved elsewhere.
PSYC has been having (2) since the start, but never implemented (1).
Ah, I think that seems more important than (2). Is that on the table for
the future?
Here I don't see the point. But that might be because in the case of BALL,
I'd expect the account handling to be done at the application layer;
not in the communication layer. I do not buy into the idea that a single
server can be allowed to maintain accounts.
so, congratulations to the Tent team for implementing something
Please someone enlighten me about the "Tent" you are talking about
here!! I vaguely recall some "tent" team from about 20-30 yrs ago.
You don't mean that one, do you?
Otherwise "tent" looks like a bad search term. :-/
Yeah, I'm impressed with Tent. Not sure why Pump.io was started after tent
(well actually, I do know why...NIH. I wonder if Pump.io also implements
this.
Yeah, pump.io - I too don't understand why that one was written.
Though I still wanted to try it, maybe there's something nice inside.
Did you?
for me this is not of interest, since i don't believe in any
federation approach at all. being able to transfer accounts isn't
a solution to anything for me - i want my communications to be
on my own computer - that's why i use retroshare and tor hidden
services until secushare is ready for prime time.
See above: same here. Except: I want my communication on my computer
AND I accept that the other party of the communication want's it
on their computer. AND I want it a backup - automatically.
AND I want (at least some) communication like "registered mail"
(that is "non-repudiation").
For those reasons I "expand" from "my own computer" to "a known
set of computers".
Best
/Jerry
......
-- [email protected]
https://lists.tgbit.net/mailman/listinfo.cgi/secu-share
