Is this a question related to this topic?
Do you mean which folder?
Am I really to answer this question? There are at least two threads to move out of this particular topic into their own topic.
I want to be able to copy the certificates from one VM to the next so they match their expected routers. I guess I cannot generate certificates and expect the configurations to magically match each other. 
Oh, sorry. Somehow I thought we were in a different thread.
Anyway, they are in the priv/cert/ directory (from root)
Thanks. Indeed, I moved the posts to another topic 
Ah, dammit, I think I need mr-b up in order to run mr-c. Will look at it later.
Mm, no. C should be able to run without B running. You can try it on debian with the localhost example.
It only says ‘trying to connect to B’ or something like that.
woops, not from root, but from example/
You can control where they get generated: try bin/gen-keys-and-certs -h.
It will indeed hang trying to connect to B the way we have it now. Try changing the remote-routers line in -c.yaml to an empty array: remote-routers: []
Added a -n option to gen-keys-and-certs to generate longer-lasting certificates, see the usage. Otherwise they expire after 1 day.
1 Like
Hi, so we finished the README and (as far as we’re concerned) the announcement page.
The API docs are hosted (due to time-constraints) on an Alleycat server here. Tonight I will revise them and then apply the 0.1.0-alpha1 tag to the repo.
Please note that I’m not working tomorrow. Feel free to ask questions (if I can’t answer I won’t) and I can try to take a look at something in the evening but this is basically it for the release!
Next steps: Arie and I have a few programming todos left. We will work in a separate branch and merge next week with the tag 0.1.0-alpha2, without an announcement.
And after that … the understanding we have with the project now (see previous posts, recent conversations etc.) is that we will take a week or two now that this part is finished and decide whether and if so how we will continue with DREAM.
I’m available for a meeting if P.S. wants to organise one to talk about this release, just not on Tuesdays. Would be nice if @tg-x is there too since it’s his design.
And after October 15 I’ll be unavailable.
It’s been real 
2 Likes
I can’t remember how to build docs. Otherwise I would try something.
I think you should go for it. I’d be especially pleased if @tg-x would lead this part since I don’t feel comfortable promoting something which I completely lack understanding.
Happy to read this. I can publish D2.2 page on Friday.
Let’s talk in a couple of weeks, see what’s up.
1 Like
opam install dune odoc # once
dune build @doc
@dvn would it be possible to have a CI job to rebuild and publish docs with each successful release? Maybe only with tags…
Hi, we were asked by @natacha to write a paragraph about upsycle-router. Here is a short description of some of its useful and unique properties and a short exploration of where we could go from here. (It ended up being more than a paragraph)
The technical side is fairly well-documented in the readme and in deliverable D1.2. The main useful properties are: it is decentralized; it uses pubkey authentication and message signatures; it doesn’t require DNS, certificate authorities, internet connectivity or authorities responsible for access control; it enables groups to collaborate using only topic keys; the architecture allows multi-hop forwarding and is resilient to processes starting and stopping.
How is it different from existing technologies? XMPP is federated and relies on DNS and fixed servers (source: tg). Scuttlebutt doesn’t have use pub/sub and peers sync everything they have (source: tg). We don’t have an exhaustive list of these comparisons. The assumption is that our particular combination of properties and functionality is a significant enough contribution to pursue and DREAM needs to decide whether or not to accept this assumption.
Things we could usefully pursue as a next step:
- improvements to upsycle-router: add Blake3 hashing, add a key-value store.
- demonstrate out-of-band peer advertisement using email, the web or a
QR-code. Peers then send topic updates to each other using the keyboard for
example. - link DMC to upsycle-router. Write a web frontend to update a DMC repo, which
then sends updates through UPSYCLE to other DMCs. For example a todo list, a
topic about whales, or a map. - improve the ‘control interface’ with which one sends commands to the MR. Implement a DSL for communicating (it currently accepts single-letter commands). This is useful for scripting / demoing but could also be an easier way for local services to communicate with their MR; the other way would be to link directly with the upsycle-router library code and call the functions in
service.ml - pursue unikernels. Why: they may save electricity and they theoretically improve security. Technically interesting: yes – requires abstracting Unix dependencies, reimplementing a part of the Angstrom stream parser, integrating with Mirage ecosystem. Effort involved: possibly high. Feasibility: uncertain, may require a week or two to explore. Emery had negative experiences with wodan for example.
- pursue end-to-end encryption for groups: Complexity: very high. Interesting and useful: yes. tg’s view is that this should happen at the application layer because different applications may have different requirements for E2E encryption.
- demonstrate two-tier architecture: also a useful property of UPSYCLE/DREAM, means configuring the software differently on a phone versus on a machine in a data center for example. Provides privacy for end-users, who can choose which core node they connect to. Can we demonstrate this with what we have? Possibly: configure certain message routers in ‘edge’ mode and others in ‘core’ mode and explore their interaction.
- implement P2P functionality, by integrating with other existing P2P libraries for example.
What is the use of this software without the peer discovery protocols (p2pcollab) which do not exist?
- out-of-band peer discovery is useful on its own: for example you scan a QR code on your friend’s phone using your own phone and you start collaborating.
- upsycle-router as it is currently implemented makes no assumptions about how the peers are discovered, so it is open to integration with any peer discovery system if interested developers want to pursue this, even if it’s not p2pcollab.
2 Likes
Thank you for this enlightening write-up!
I assume this comes from the proposed design. But ERIS currently uses Blake2b, wouldn’t it make sense to follow this as well in order to minimize dependencies, or have ERIS use Blake3 as well? What does it entail in terms of adoption, and therefore code maintenance (if we must create the missing packages)? I guess @emery could give a hint about this, and upcoming plans for ERIS 1.0 specification.
This is indeed one hell of a wanted upgrade. We’re going to talk about it in the upcoming meeting, and especially wrt alternate announcement / synchronization processes.
Very interesting views. The high complexity things can go to another research round I guess, but for the demo we need to figure out the right angle. Let’s see what we can come up with.
1 Like
I think message router is great and definitely worth pursuing, however is is essential to have a comparison with other existing systems in order to understand its specificities and be able to give it a life of its own.
Indeed Upsycle Design document mentions IPFS, but makes no mention of DAT protocol, I do not have much understanding but it seems from the description I read that DAT is also asynchronous, is this right? In all cases DAT is agnostic of transport, therefore could DAT use UPSYCE Router, and would this make any sense?
There is an interesting comparison between IPFS and DAT might be useful: Dat Questions · Dat Docs