This project has probably been abandoned.



Contents

Description

Saikound is a next generation PSYC server for clients such as Purple. Saikound employs libpsyc and is able to host contexts and identities.

Saikound is written in D (D1 and Tango to be exact). The plan is to have an easily configurable and extendable daemon with reasonable default-fallbacks. Entities will be stored as serialized PSYC packets using libpsyc.

It will be able to load C libraries on the fly as well as start other binaries. Both can then control one specific, a certain subtype, or all entities. They could also just provide a gateway to other networks, so that packets to that protocol get routed over them.

Saikound, libpsyc and purplepsyc are being developed in parallel, they are used to constantly test each other.

GitLink: git://supraverse.net/saikound

OhlohLink: https://www.ohloh.net/p/saikound

ProjectManagementLink: http://redmine.supraverse.net/projects/saikound/ (vote for issues you want to see implemented!)

PSYC context for git Updates: psyc://supraverse.net/@git

How to setup a D environment by fawzi

flattr-badge-large.png

Future

Saikound currently fulfils similar jobs to psycd, we may re-engineer it to become a high-level extension of psycd at some point instead. For now our development focus is on psycd.

Eventually, saikound should have a neat styleable web interface, so it can be installed and maintained easily on a DSL router box or similar device. Marenz wants to use it as a development platform (wiki, forum, bugtracking) as well as facebook-like social networking, and messaging and chat obviously.

In the meantime psyced will continue providing XMPP and IRC gatewaying and other features it is really strong at, but pass routing down to Saikound or psycd for improved privacy.

Check out secure share for the big picture.

Compilation Requirements

Questions

If you have any questions about the project, contact Marenz via

Current Status

Here you find regular updates of the progress of the development.

WIP

  • Marenz
    1. integration of libpsyc's renderer
    2. re-organisation of the dispatcher to be more modular
    3. subscribing to contexts on other servers
    4. subscribing to places
    5. link management to a users identity
    6. multicasting/chatting in a place (with psycpurple and saikound)

July 2011

We are evaluating F2F technologies.

12 June 2011 (latest)

We are using libpsyc now for rendering. Some reorganisation happened, too. And more to come

15 October 2010

I decided to do only major updates here, and smaller updates at ohloh (see link). We finally managed to get the plugin system working and are very happy about it. The cmph was a mess to use and triggered random segfaults, so we got rid of it (it would have been a very minor speed up anyway, it wasn't worth the work). We have a new plugin type called storage.

Oh right, we had to change the compiler because dmd is unable to produce working shared objects. We are going with ldc now. However, we plan to still allow dmd just without plugins (they would be compiled in then)

So yea, now I can finally work on the psyc logic.

26 September 2010

some work on the plugin system has be done (a little redesign). I added a binding for cmph, a minimal perfect hash function generator library, to have a very fast and space efficient lookup map for the methods in which different plugins hook into. If everything works like it is now, I can start implementing the logic of the links channel soon.

19 September 2010

purplepsyc now successfully opens a tls connection, authenticates using srp and sends a _request_context_enter message to its identity. Now I need to fix the server so it answers

18 September 2010

YAY! first successful authentication with libpurple using gnutls+srp. Now the real work can begin.

17 September 2010

We wrote a pluginmanager. Using it, we now have Context/Channel modules which can hook in any method that a psyc packet might send. It still needs testing.

14 September 2010

We updated DDL and tango to work with the latest dmd.

Thus DDL works. It now needs proper integration and tests. No progress on TLS/SRP because it kinda depends on DDL right now.

3 September 2010

GnuTLs SRP Auth now works. The created connection might still have some quirks though, need to work on that. I also started to implement it in libpurple for pidgin. html also made some progress, but I can't compile it with my dmd version currently, and I am busy with tls anyway ;)

2 September 2010

GnuTLS auth is making progress. the gnutls-cli test client can already connect, but fails so far because no user exists ;)

html created a second branch for experimenting ddl things. Due to dmd bugs, you have to use the older version dmd 1.052.

31 August 2010

Thanks to html, a new contributor, saikound now supports chroot/jailing.

Welcome aboard!

In other news, I've been working on gnutls integration which will give saikound srp capabilities.

--Marenz 21:00, 31 August 2010 (CEST)

16 August 2010

Right now I am evaluating different ways and concepts of how authentication and encryption should be handled. Lynx says that GAP is the way to go. I had a look at it. I think it is quite some work to do this properly. I would move it to post-1.0 versions.

In this version I feel an attraction to OTR, TLS with SRP, and TLS with PGP, as well as symmetric keys for channels that periodically update (depending on an paranoid factor).


In practice, my idea would be that every one-to-one communication with an entity is OTR encrypted, which means everything but the routing information. So you could see who talks with who.

It maybe is possible to hide the sender, but it complicates things a lot.

The sender could be encrypted (for example, it could be something like psycenc://<some salted hash value?> and the salt could be in the content section). But this gives us problems too, as the servers no longer can make sure that the client is who she claims to be (as it is invisible to see who he claims to be).

I think for now only the content will be encrypted


SRP would be used to authenticate the client against the server and if encryption is desired, to secure the TLS connection.

For registering, when the user doesn't have a password yet, the server could use a PGP infrastructure, but I don't know much about PGP yet, so this needs further work and will be postponed. I will use anonymous or self-signed TLS in the meantime.

I ask you for comments on every part of this topic, also in the appropriate wiki-pages, though, I feel like a clear overview of what psyc desires and what path it should take is needed.


5 August 2010

  • flexible logging system due to tango
  • Ini parser for configuration
  • Circuit establishment
  • Packet forwarding to the appropriate entity
  • Context subscription and maybe even unsubscription

--Marenz 18:44, 5 August 2010 (CEST)

Contribution

Styleguide

The sourcecode should be formatted according to Walter Brights Digital Mars StyleGuide. With the difference that we use the TAB character, not spaces.

The documentation of the existing code is somewhat lax so far, I am working on that. New code should be documented as the StyleGuide specifies.