[ticker-dev] Ticker group "invitation" attachments

[Phillips, Matthew]

[David]
> -->"Matthew" == Phillips, Matthew 
> <Matthew.Phillips at dsto.defence.gov.au> writes:
> 
>   Matthew> I was kind of just seeing this as a natural complement to
>   Matthew> the key file format.
> 
> That's a reasonable model, I reckon.  But being lazy, I just 
> figured that using ep/ec syntax, and notification-compatible 
> naming made more things easier in future ... :-)

I agree, I like the simple format. But it's easy to hit the limits.

>   Matthew> But being able to optionally embed the key(s) with the
>   Matthew> invitation would make more sense - I didn't go there
>   Matthew> because the name/value format isn't composable. Dare I
>   Matthew> mention XML? ;)
> 
> Maybe MIME's multipart/related (RFC-2112) and CID URLs 
> (RFC-2111) would be a better approach?

That also sounds like work, and it could be fun seeing if the MIME parser I've snaffled will deal with that ;)

> Well, you could compose them using XML, but I think keys and 
> groups are better as independent entities?

The nice thing about XML is that it allows keys and groups to be separate or embedded eg:

<group version="1.0">
  <name>Private Chat</name>
  <type>chat</type>
  <defaultSecure>true</defaultSecure>
  <allowInsecure>false</allowInsecure>
  <keys>
    <key version="1.0">
      <name>Private Chat</key>
      <access>shared</access>
      <data>xxxxxxxxxxxxxxxx</data>
    </key>
  </keys>
</group>

i.e. the embedded key(s) just follow the format of a standalone key.

A bit offtopic, but does anyone have any feeling as to whether the above is more "correct" XML or the following:

<group version="1.0" name="Private Chat" type="chat">
  <keys>
    <key version="1.0" name="Private Chat"
         defaultSecure="true" allowInsecure="false"
         access="shared" data="xxxxxxxxxxxxx" />
  </keys>
</group>

I like the terseness of the above, but it somehow doesn't feel right ;)

>   >> In the case where the receiver doesn't already have the key, and
>   >> the use of an existing, secure Elvin channel to deliver it
>   >> doesn't exist, then you're left with other means: a PKI, HTTP(S),
>   >> email, sneakernet, SMS, voice, etc.
>   >>
>   >> This is where Jinx tried to help -- if you can send a message,
>   >> with deliver_insecure set false, and including the known public
>   >> keys of all intended receivers, you can send the key inline ...
> 
>   Matthew> You can do that with Sticker too btw.
> 
> So could you safely include the keys in a ticker attachment, 
> since you can control who sees it using their advertised key?

Yep.

>   >>  I guess it wasn't a major release, but it brought it up to spec
>   >> with latest v3 rules, added the ability to reload your keys file
>   >> without restarting and added the use of SIGHUP to cause a reload
>   >> of all config files.  Fairly major improvements albeit not
>   >> especially visible ones.
> 
>   Matthew> V3 support is good. Now all we need is Aquatik to do v3
>   Matthew> (fully ;) and we can drop the v1/v3 hybrid ticker messages.
> 
> And all the various bots, applets, etc, that continue to use 
> v1 format messages.
> 
> But you're right -- it's a fine thing :-)

Do any bots out there *listen* for v1 only? I imaging we'll have to listen for v1 forever, but at some point we can stop emitting it from user agents.

Matt.