I will be giving a workshop in University of Aveiro @ Portugal

[satazor]

Obviously it will be about peer-base!

Date: 20/12/2018 18:00 GMT
Description:
https://gist.github.com/satazor/055de251c823048817812c427e2ab604

Here’s what I’m thinking:

1. Introduce the web of today and the web of the future. I will be giving a small talk similar to the one I gave at OPO.js, explaining how highly centralized the web is today and how it can be different. After the talk, attendees will understand what decentralized/distributed web is and the possibilities it gives.
2. Give the Todo Dapp workshop. I will be also buying a WiFi hotspot in order to show the true potential of peer-base: online, LAN and offline scenarios.
3. Quickly showcase peerpad and discussify
4. Will finnish with some more inspirational sentences so that people get inspired to experiment

@vasco-santos Will be helping me!

[satazor]

What are your thoughts?

[pgte]

@satazor this is great, thank you for letting us know!

When using a Wi-Fi hotspot, are you planning on being connected to the public infrastructure, or will you be running your own rendezvous server?

[satazor]

I was thinking on using a local rendezvous server from the start. The hotspot will not be connected to the internet, it’s there just to demonstrate that we can collaborate together without a connection to the backbone.

[satazor]

Also, to show that it works online as well, I can ask to switch to the university WiFi instead and ask to remove the swarm address. If it’s flaky we can switch to a local rendezvous, or even several ones running on attendees machines. Not sure if the university WiFi blocks some ports though.

[dirkmc]

I liked David's point about the "wow moment" when you pull out the network cable that connects to the internet. I wonder if you can simulate something similar with a router, showing that you're connected to eg google one moment, then pulling out the cable and refreshing to show you're no longer connected to google but you can still keep running over the local network.

[satazor]

Yep perhaps it’s better to start with the online version (using PL WS), then switch to the local WiFi hotspot and offline and back online. That will give the wow effect :D

[pgte]

Here is a quick video of me showing how you can configure peer-pad (and peer-base) to use 2 addresses (a public and a local one) at the same time to still be able to connect to each other after I switch the internet access off:

https://www.youtube.com/watch?v=XTgE2tA6Zhg

[pgte]

@olizilla @lidel we briefly talked about this (having multiple websocket-star rendezvous servers) at the latest GUI and WB WG meeting ^^

[pgte]

(just made the video public, sorry if it wasn't before)

[lidel]

@pgte that's interesting! So as long both are online when the node starts (to avoid crash as in ipfs-shipyard/ipfs-share-files#63 (comment)) either of them can go offline at any point at a later time without causing any crash?

[pgte]

@lidel correct, as long as you diligently handle disconnects / reconnects (if you're implementing a libp2p protocol). YMMV regarding specific libp2p / ipfs protocols (like bitswap), and it would be cool to have that experimented with! (Since I suppose there may be no or little automated tests for offline / partial / intermittent connectivity).

[satazor]

@pgte Ideally, I would have two swarms: one pointing to a local rendezvous on the same LAN and another pointing to the one hosted by PL. This would allow me to "pull" the cable of the WIFI router and people would still be able to collaborate, even if they refresh the page.

At the moment, because the one hosted by PL became unreachable when I pulled the cable, IPFS doesn't start.. even if the local one works. Is there any way to get around this?

[satazor]

After reading this thread, it seems I can use https://www.npmjs.com/package/libp2p-websocket-star-multi to point to a local one and the PL one. Have you used it previously @pgte?

[satazor]

The workshop went very well, everyone were able to follow it through and collaborate together on the TODO list, both online and in a (offline) LAN. A lot of questions were asked about IPFS and how the replication worked and so on, which means that people were really interested in knowing the internals.

Here are some photos:

Some takeways/improvements that we really should focus to improve talks/workshops:

• Solve the fact that IPFS won't boot when configured with multiple swarm entries and one of them is unreachable. This "sucks" because it doesn't allow us to "now go offline and see that it still works" when people refresh the page.
• Allow people to access my local IP and "follow" what I am doing in my machine. The reason is that the local rendezvous socket server is a ws and not wss which breaks the security context. It would be cool if we could add support for wss with self-signed certificates.
• The same thing applies to the local IPFS gateway. One has to use https://github.com/naugtur/https-proxy-cli to do just that, but it would be cool to have this built-in perhaps?
• There were some issues when installing peer-base on some machines due to missing/mismatching stuff on OS. @vasco-santos can you elaborate on this?
• We couldn't fetch a CID from the ipfs.io gateway. We really couldn't understand the issue, either the ipfs.io gateway was borked or somehow the gateway couldn't reach the machine behind the university WIFI.

[pgte]

@satazor thanks for this, this is great!
Could you please make sure each of these opportunities for improvement have their own issue on the root-cause repo?
Thanks!

[vasco-santos]

Regarding the issues installing peer-base, they all seem related to ipfs / libp2p, but should be taken into account. There were people with all type of environments and package managers. IIRC, there were people using CentOS, Fedora, Xubuntu, among others.

List of common problems that people had in their environments:

• need to have node-gyp installed globally
• node-gyp requires python2.7, while there were people who only had python3 installed and got issues until switching to python2.7.
• build-essential package needed
• gcc-c++ needed

I would say that we should have a FAQ installing questions with the possible problems installing ipfs and how to fix them.

cc @alanshaw @jacobheun

[pgte]

@vasco-santos thanks, that's also useful insight! Could you please open the respective issue on js-ipfs?

[satazor]

• IPFS refuses to start if one of the swarm entries is unreachable: inconsistent node startup behavior depending on attempted ws-star swarm binding ipfs/js-ipfs#1619 (comment)
• WSS support for rendezvous: Add WSS support libp2p/js-libp2p-rendezvous#5
• HTTPs gateway support for js-ipfs (and probably Go as well): Consider adding support for a HTTPS gateway ipfs/js-ipfs#1789

[satazor]

@vasco-santos can you create the issue regarding the installation of IPFS on some OS's and link the issue here?

@pgte regarding the the ipfs.io gateway not being able to reach my computer under the university WIFI, I don't really know what was the issue. What do you suggest to do here?

[vasco-santos]

yes, I will create the issue

[pgte]

@satazor you can add that issue to js-ipfs.

[satazor]

Probably related to the ipfs.io gateway issue we were observing: https://github.com/protocol/infra/issues/410#issuecomment-449551816

[satazor]

Closing this and we shall track all the mentioned problems in their respective issues.

Thanks everyone for the feedback!