On Sun, 07 May 2000, Brandon wrote: > > What metadata do you need to implement? The storable fields ARE the > > metadata, > > any other metadata should be in the trailing, not in the message, like we > > decided. > > Right, I want to make the clients read the metadata stored in the trailing > field and I want to use the same code that RawMessage uses to read fields > to read the information in the trailing field because while the trailing > field could be in any format and the nodes wouldn't care, I think the > clients should all use standard field formatting.
Cool. This should fit very well with the FieldSet abstraction, since the trailing is otherwise not a message. > > Nodes need to be able to talk to one another. We should not have it so they > > can't. > > But it is inevitable that people will want to add different message > encodings and that not all nodes will be mutually interoperable over all > encodings. For instance, there is already the desire to encode Freenet > streams with SSL so as to mask that they are Freenet streams. How can we > add this capability without supporting multiple protocols and specifying > the protocol explicitly in the address? I don't see how you can make it work _with_ support for multiple protocols. If my node supports standard FNP (Free Network Protocol) and some very rare SSL version, SSL/FNP. So I get a request from a node that uses SSL/FNP for document lala. I have lala so I send it back. What type of address do I put as the datasource? Or the other way around. I get request, send it to the SSL/FNP node, which replies with the data and itself as the datasource. Do I pass it on knowing that most nodes can't access SSL/FNP, or do I change the DataSource? One could say a message could have several datasources using different protocols, but knowing the address of several nodes upstream makes it a lot easier to trace the path of a request. > > I think we should spend more effort on forwards compatibility for the > > versions > > of the protocol that will actually be used. > > True. I was just mentioning that because it's a nice and useful side > effect of implementing multiple message protocols. The reason I really > want it is for forward compatibility and because my node should be able to > speak to both normal Freenet connections and SSL connections. It should be > able to pretend to be a webserver, FTP server, etc. and still talk to > normal Freenet nodes and we need some way to tell a node if the thing it's > connecting to is going to act like a normal Freenet node, pretend to be a > webserver, etc.. The encryption is not the only important change that will break the protocol. We need to change the message names and implement fallback on message types. The we need keytypes. With those two in we should have pretty good forward compatibility. > _______________________________________________ > Freenet-dev mailing list > Freenet-dev at lists.sourceforge.net > http://lists.sourceforge.net/mailman/listinfo/freenet-dev -- Oskar Sandberg md98-osa at nada.kth.se #!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj $/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1 lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/) _______________________________________________ Freenet-dev mailing list Freenet-dev at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/freenet-dev
