After trying to bring the conversation together with what I've learned from rooting around in the .config folder, this is my current understanding. I know the sync description is wrong, it's just what I understand of it right now. I would appreciate corrections towards common usage.

We have:

• contexts. Everything in SyncEvolution happens in a context. A context has a name, and holds some commone properties that are applicable to everything in that context: logdir, maxlogdirs, and deviceId. These all have sensible defaults, so we won’t be bothering with these right now.
• sources. A source lives in a context, has a name, and describes a database of (either) contacts, events, tasks or memos, using the following properties:
  • backend: the storage engine (such as file, caldav, activesync, …)
  • database: the location (file path, url, whatever) that describes where the database can be found, possibly relative to the peer syncURL
  • databaseFormat: the format of the items in the database, in case more than one type is allowed by the backend (currently only relevant for backend ‘file’, which supports text/vcard and text/calendar
  • databaseUser: the username to access this source, if not specified already by the peer (more on this later)
  • databasePassword: the password in the same vein as databaseUser
• peers, which describe the ‘remote side’ of a local-remote sync. This only describes how to reach and access the peer in general, not (yet) how to reach any source inside it; more on that later. These contain loads of properties, but the most interesting are:
  • username: the username to use when accessing the a source associated with this peer. Note that for example you could access the same source with different credentials (and thereby possibly getting different items returned from the same source, based on an authorization scheme)
  • password: like username
  • syncURL: specifies how to contact the peer, for example the caldav or EAS url
• syncs, which tie together a remote peer, a local source and a remote source. This has two properties of interest:
  • sync: defines which way the sync goes, can take values ‘none’, ‘one-way’ or ‘two-way’ (one-way being seen from the local side of the sync)
  • uri: specifies the source for the remote peer.