Feedback from MozFest 2018 workshop

[olizilla]

The workshop code is great, this is mostly feedback on how we present the workshop, from the MozFest 2018 event.

Start with the simplest demo of "what is IPFS"

Even tho the demo is not about IPFS, there were people in the audience who were there to find out more about IPFS and didn't have a mental model of how it works or the role of the http-to-ipfs gateways. We were demoing the magic of content addressing and gateways with @rumyra like^*

$ cat hello london | ipfs add -Q
QmPDnRQ13M6Khw22DGKHPcsYdPMXFLHHxTpuJTrbugLjv8

# the content is available locally...
$ open http://127.0.0.1:8080/ipfs/QmPDnRQ13M6Khw22DGKHPcsYdPMXFLHHxTpuJTrbugLjv8

# and from the ipfs gateway!
$ open https://ipfs.io/ipfs/QmPDnRQ13M6Khw22DGKHPcsYdPMXFLHHxTpuJTrbugLjv8

# and from the cloudflare gateway! WAT!? OMG!
$ open https://cloudflare-ipfs.com/ipfs/QmPDnRQ13M6Khw22DGKHPcsYdPMXFLHHxTpuJTrbugLjv8

^{* or use asciify for more fun}

...starting with this introduces the idea that even the static files of the demo can be hosted on many peers rather than a central server, and it acts as a quick magic trick to get the attendees hooked before diving into slides and code.

Map the roles from the central world to the decentral world.

The slides have a good diagram of what is needed to host a webapp in the central model. I don't think we need to spend much time on that, as the audience with either know it already, or they won't and we don't have time to teach them... they probably didn't come to the dapp workshop to learn about the old way.

It is a super useful slide though, we just need to define the pieces of the the centralized version as "roles" or "services" (database, rest api, etc) and show that traditionally, a lot of these roles live behind the single central url domain of the service provider, and then show how a lot of the roles move out to the peers and the network in the dapp world.

Showing how the db moves from the central host to 1 db per user* also nicely segues into "but how the heck would we merge everyones changes? what about transactions? wouldn't there be merge conflicts!?"... OMG CRDT MAGIC!

*(make sure to explain that it's indexdb by default, so everyone is clear we're just using web tech in this example)

Give a non-technical introduction to CRDTs

We don't have time to explain how CRDTs really work, not should we in a ~1hr workshop on dapps. The job is to get people excited about them so they read up about them in their own time, and are clear on the value and the trade-offs of using them.

The simplest headline for them is No more merge conflicts! with enough computer science you can let many users edit the state locally, and all those changes will always be able to be merged cleanly into a consistent global state. As each peer recieves updates from others, the will all converge on the same state.

This is magic, and magic should cause excitement and fear. Anyone who has written code for a while is sceptical of magic, and it's on us to explain what the trade-off is that makes the auto-merge possible. To make it work, CRDTs only support a limited set of possible update styles... you can only changed the shared data in certain ways, so you have to be able to map the way you want your app to work to this limited palette. It'd be fun to mention some of the interesting flavours that we know about so far, grow only set, etc, just to give the idea.

What is the privacy model of this app / IPFS in general

We got asked the "how is privacy managed when you have a public pinning service" and related questions about how privacy is managed in this app. This app is a tech demo but its worth defining the privacy expectations people should have, and also being able to answer questions on IPFS and privacy more generally.

Get a location that works for a workshop style session

The workshop at MozFest went well, but it was harder for @pgte and @satazor than it needed to be as the space was noisy and open, and the tables were in a long thin line away from them. People at the back struggled to hear, there was a lot of background noise, and the time slot was right at the end and we had people packing down the festival before we had finished and a couple of people had to leave.

I think it'd be fine to question the scheduling of putting any workshops on that are timed to finish at the same time the fest is due to end, and a workshop style session needs a room, or at least a quite space. It'd be totally fine to make that a requirement once the session has been accepted. Ravensbourne is University, it has loads of rooms.

[olizilla]

[pgte]

@olizilla Thank you so much Oli for this careful feedback! I'll be taking a look at these (and remember the feedback we got from other attendees) and proposing some actions.

[pgte]

Completed my report of my experience at the 2018 MozFest.

In hindsight, I agree that we should have prepared more the layout and space to make the workshop more comfortable and accessible.

The privacy concerns were a constant subject during the conference, whenever we mentioned DApps. If people are going to pay the price of the effort for decentralising, they want to know how much of an advantage it is in comparison with the centralised model.

Let me even add that, by my sampling, I think the type of people coming here were not terribly interested in "quickly turn my app into a app by using this one library", but were more keen in

1) learning and discussing the architecture of a DApp 2) discussing some of the security and privacy properties of DApps.

I think show and tell is fine, but I think we would engage in more meaningful discussions if we prepare the above.

I think the workshop is very valuable in itself, but it could simply be a link at the end to let people try it out at home later.. or the subject of another session.

Idea

Better yet, why not suggest a "decentralise-your-app workshop", where people do their homework (workshop), apply it to a given app (much like Juan did with the chess game), and then come in to show and get feedback?