[Ndn-interest] Email over NDN

Alex Horn nano at remap.ucla.edu
Fri Sep 5 13:03:16 PDT 2014


can’t speak to how it’s ‘ill suited’ - but i can point to past work
<http://named-data.net/publications/techreports/trlighting/> that
demonstrates signed interests in NDN, and of course Wentao's further work
in NDN-JS and BMS

also, the lighting control during the demos yesterday used signed

more generally - the following is a follow-up to our discussion yesterday /
what your poster made me think of.

(to those not familiar w/ his poster, his proposal is a sort of 'NDN
Pinterest <https://www.pinterest.com/> or Mural.ly <https://mural.ly/>'
(all apologies Felix :))

what I was trying to say yesterday re: ‘documents’ -

a) each ‘document’ is a merkle tree
<http://en.wikipedia.org/wiki/Merkle_tree> of the names (including
versions) of the elements
you call them bits, i’d change that terminology for this crowd :)  - i used
‘elements’ in my namespace)

b) there is a ‘link <http://named-data.net/doc/ndn-tlv/data.html>’ data
object that you can use, avoids duplicating content by linking back to a
different content object. it’s like a filesystem symbolic link. Likely not
necessary in initial implementations, but something to keep in mind.

here is a potential app namespace:


the [element] above is shorthand for:


in this way. each user has


this is potential way for users to include other user’s content/elements in
their ‘documents’, and it will automatically allow each user to update the
elements in their document, or use the element version that they created it
with (or any other version).

anyway - this is what your poster made me think of...

it could arguably even be implemented by sticking data
NAME] in exiting HTML Divs.

that way you can replace content in the divs with the content of the NDN

in this way you can use a browser as-is, and use NDN as transport.

this can all be done with javascript, with a  back-end repo
<https://github.com/named-data/repo-ng> on same machine as NFD to store
content permanently.

note there would be some discussion w/ team required to see what prefix
(other than /ndn/appname/) should be used to make your application globally
routable... but you can pick any prefix for development, and make sure it's
easy to change when ready for others to use :)

anyway, just some notes & suggestions to start,  likely better ways.



On Fri, Sep 5, 2014 at 10:54 AM, Felix Rabe <felix at rabe.io> wrote:

> Hi
> This morning I was having a short discussion with someone about email over
> NDN and how current protocols are ill suited to secure replying and
> forwarding of signed messages.
> I can't remember who you were; please quickly drop me a line to
> felix at rabe.io. I'd like to continue the discussion.
> - Felix
> _______________________________________________
> Ndn-interest mailing list
> Ndn-interest at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20140905/cb5884c9/attachment.html>

More information about the Ndn-interest mailing list