A list of specs that should be decided on and frozen to advance new psyc implementation.
(draft, please add details)

Contents 1 Spec TODO 1.1 To do later 1.2 More to be done: 2 Style of documentation

Spec TODO

1. Talk:Spec:Syntax changes DONE
2. Circuit establishment
3. finalize Spec:Context subscription
   • context state, so that we can keep a list of members etc
   • one-on-one messaging should be a special case of a context
   • come up with a table syntax for the list of peers or members and their respective trust values
   • controlling places via trust
4. Friendship vs Trust & Presence
   • when replacing friendship with trust maths we have to think of how to map psyc friendships to XMPP and back (unless we drop XMPP gatewaying as it will never have the same privacy level anyway)
5. The big keyword naming revamp and the compact mode shortcut tables.
6. File transfer for crypto sharing purposes.

To do later

1. Spec:Linking needs more experience with SASL, SCRAM and SRP, or we declare client/server relationships obsolete/low-priority and expect the "server" (a router daemon) to always be available via unix socket on localhost.  ;-)
2. Spec:Variable (Discussion) types
3. language/localisation?
4. getting general information about entities WHAT? we subscribe to them, end of story!
   • like topic of a place, full username, time zone, fotos, whatever
   • state, profile .. you get that when you sub an entity
   • Context Interfaces
5. Interfaces and Signatures?
   • Storing client configuration variables on server
6. Fancy formatting of text
   • like font, color, size of certain parts of the message, or the whole message
7. Remote PSYC Authentication (not linking)
8. Packet ids to ensure no packets are missing
   • Do we need routing modules negotiated during circuit establishment? (_compact, _state, _signatures?)

See also the general PSYC roadmap.

More to be done:

1. standardized way to localize templates and select their language
2. option to not receive templates for standard messages
3. option to receive rendered messages instead of templates

Does this belong with the module negotiation?

Style of documentation

<Marenz 22:16, 31 May 2011 (CEST)> I want to suggest to describe every entity-describing part of the spec pretty much like http://about.psyc.eu/Spec:Context or according to a yet-to-be-written example. I'll try to describe Spec:Circuit like that..?