[ticker-dev] Ticker group "invitation" attachments

[David Arnold]

-->"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 ... :-)

  >> If you're going to send the key around in email, you might as
  >> well attach the invitation as well -- then the receiver can
  >> "open" the attachment, which should subscribe them (probably via
  >> a confirmation dialog box).

  Matthew> Good point. Although I tend to re-use keys and so, once
  Matthew> they're exchanged, an invitation that refers to them would
  Matthew> still be useful.

Yep.

  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? ;)

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

Maybe MIME's multipart/related (RFC-2112) and CID URLs (RFC-2111)
would be a better approach?

This would also imply that the value of the *-Keys files would need to
allow URLs.  Which might be a good thing anyway.

  Matthew> An alternative would be to just treat the SHA1 of a the key
  Matthew> as its ID? (or the key itself for shared keys).

Hrm.  I guess that might work ...

  >> 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?

  >> Also, it'd be nice to specify a file extension while we're at it,
  >> so you can get suitable icons for such files in file manager
  >> apps, etc. The "tt" prefix is kinda taken by TrueType, so "tts"
  >> seems likely to be collision-prone -- any other suggestions?

  Matthew> That would make sense, but I certainly wasn't planning to
  Matthew> actually implement anything like that :/ Managing
  Matthew> registration of file extensions is just Too Hard (tm). For
  Matthew> now I'm just allowing copying of key text from anywhere and
  Matthew> allowing it to be pasted into Sticker.

Drat ...


  >>  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 :-)





d