# IPFS Personae: Engaged-Partner Discussion

## Audius

### Participants
- Hareesh Nagaraj
- Roneil Rumburg

### Tell us about your road to IPFS ...
**R:** Music/Content network: decentralized Soundcloud. Help fans discover/follow, and artists connect.
**H:** **All** content is hosted on IPFS. Including profile pix, etc

### What led you to IPFS?
**R:** IPFS came before "let's build this." Heard through Media Chain (Jesse and Denny). There was too much for one co to do, needed decentralized. 1.5y ago I built a proof of concept. H was here from hearly days, doing storage protocols. Met Juan in the context of financing (2015), turned down offer!
**H:** Decentralized is critical to what we do. R: IPFS is an existential necessity.

**J:** (Shares Mural) People use IPFS for a huge array of reasons, so we put together goal-based personas. Your co and yourselves align with at least two of these roles. (Briefly describes each one)

### What persona(e) did you fit into?
**J:** Did you have music-industry backgrounds?
**R:** Was involved in the music scene and met Arkady. Early cofounder was in the industry. Another cofounder was involved with cataloging The World's Music previously, from a more commercial standpoint. We thought this could be attacked from a more altruistic standpoint.
**R:** Content-based addressing is key, because it's evident if it's been modified (re Archivist persona)
**J:** How did you find documentation and info?
**H:** Was kind of a fire hose of info at first. Not really sure what category we would fall under.
**J:** What resources did you use — or wish you had — to see how IPFS fit into your tech stack, eg?
**H:** Understanding how best to run IPFS in the context of a greater application. Used js-ipfs at first, and ran into some issues which were then solved by the go version. The docs were clear, but running it in the context of an application (less available). The js version seemed unstable, eg re high memory usage with nodes. So we decided to use the "gold standard" implementation instead.
**J:** (describes potential overview in the docs of the various implementations and pieces)
**R:** Didn't even know Cluster existed until camp.
**H:** If we had examples, that would've been very useful.
**R:** Case studies would've been very useful, showing how some people use IFPS.
**J:** Would a more general case study be useful?
**R:** Something more vague like here's how you could set up a decentralized content network might be useful.
**J:** If we were vague with some recommendations, would that be annoying?
**H:** If it was framed like a white paper (ie more generically?)

### What do you think of how we've captured those personae?
**J:** These are super broad, but look at these (and we'll discuss how well they represent reality to you)
**R:** Captures it pretty well. It is very broad, as you referred to. Definitely reflects our fears. A lot of people in this cat would care about permanence. I would downplay security a little. You'd want to probably do end-to-end encryption, and not rely on IPFS for that. Everything is public, so security is less of an issue.
**H:** Our use case is very different.
**R:** Permissioning isn't really possible in decentralized systems without end-to-end encryption.
**H:** (Re data integrity) Our content needs to be available.
**H:** We had to breakdown multihash on our own, and how (the concept of) blockchains were related
**R:** An official (???) library would've been very useful.
(Re Archivist)
**H:** Protoschool is huge. If that had been around at the start … Having the ability to interact with the tech without having to set it up. Coming from no background, I could go to protoschool and try it.
**H:** Wiki-related people, eg, are very interested in the decentralization aspect.
**R:** Permanence is very important. We have to make sure there's redundancy and replication.
**J:**
**H:** Cluster doesn't really fit our specific use case. We might've used it for *our own* cluster.
**R:** IPFS is like the routing/network layer. Filecoin would be (how we can be the data can be guaranteed to not go away)
**R:** The logical progression of IPFS: It's like HTTP, filecoin is like the S3. They complement, rather than being the same thing.
**J:** Have you used the forums? What frustrates you re this and the docs?
**H:** We try the docs first. They're very comprehensive. I have posted on discuss.
**R:** The forum is how we first got connected with your team. But didn't get a response at first. I knew Jesse C from school, pointed me to Arkady (already knew him). ... So the first experience wasn't great (but the question was a little esoteric).
**R:** (Describes how they have been primarily interested in *how IPFS might be used*, as opposed to whether this new IPFS thing might solve their problem)
(re developer persona)
**H:** Versioning is very important.
**R:** Have been frustrated over inconsistent features between different implementations of ipfs. We've had to hack around that in a few ways.
**J:** Would a big feature chart be helpful (yep)
**H:** The difference between setting something up and productionizing things is very big. Textile materials helped.

### Are we failing to serve any audiences with these personae?

### Additional feedback
**H:** A lot of things (eg how to use a json file) have no example. How to use the public gateways.

## Textile

### Participants
- Andrew Hill
- Carson Farmer

### Tell us about your road to IPFS ...
**A:** Interesting q, seems like ancient history. Carson do you remembver learning IPFS??
**C:** When we started learning IPFS, we blogged about it. There weren't a lot of examples, so we figured others could benefit from our experience. Would google "can ipfs do this thing?" Often not much there, so were foolish enough to figure it out and write about it ourselves.
**A:** I met Juan in 2015, it went way over my head but packed it away in my head as something to learn about. Later worked with Blue Yard so ipfs was on the mind more. ~2017 were looking for content-addressable data. They knew Blue Yard was on the ball [so that gave it caché.]
**J:**
**C:** This looks like something cool … data sovereignty, user control, and ___ made content addressing seem like a really powerful concept. Then asked if ipfs can handle the types of content they wanted to deal with. They looked at use cases they envisioned, how easy it was to build on top of (especially re mobile!). Initally thought js-ipfs would solve that. Tried experiments, and found it wouldn't work. Then found Open Bazaar and that was a positive example.
**J:** What would've made the journey easier?
**C:** We did what we envisioned at the time. How to set up a cloud instance, how to create a simple js app, chat, etc. Not necessarily what the project should be doing [because very specific].
**J:**
**C:** Part of me is "I don't know if i want ipfs docs to get better!" [because competition heh … kidding] Matt started his company based on your tutorial. [mentioned their Build video tutorials]
**J:** We have a larger issue of integrating content from groups like yours. Want to be sure we're giving credit, not co-opting, etc. … You wrote about what you _wanted_ to do …
**C:** The Build series is a little more about general, because we wanted more devs to build stuff with us. So those don't focus on textile per se, but allude to problems we might solve.
**A:** A lot that was self serving, bc we wanted to build user-facing apps. So the focus was on that, and we knew that was a difficult thing to do.

### What persona(e) did you fit into?
**J:** [Shares mural, describes] I'd like to see if you as devs and teachers feel as though these stand up to scrutiny, and want general thoughts
**A:** From a quick skim … all make sense to me, but i can't say if any are missing.
**J:** [Yes] Maybe we should start from the bottom and work our way up. Bc you are always a dev and … (something else)
**A:** First thing that jumps out is how catch-all that guy is. Devs are tricky, our experience is that they come in with much more specific objectives when they come to ipfs. There's a whole community that's looking to build apps that run on CRDTs. Then they hear about IPFS and want to see if it is a good option for that.
**J:** Good. Let's table that and move up to Big Data folks.
**A:** Also splits into two distinct groups with different measurements. Corporate and academic (business/social is the slider). A project i worked on called GBIF: Global Biodiversity Information Facility, almost flipped from your use case here. A federated network of natural-history museum collections. The value is directly tied to their specimens. So if they lose control of their data, they lose their value. IPFS is a perfect fit. Their motivation is very different from what you have here. It is driven by where they can get funding; if they can get influential museums interested.
**J:** If you think of the archivist as concerned with permanence …
**C:** Each of these people are actually devs. I recognize the privacy-aware communicator, but i don'/t know if the data-integ is very different. I would be surprised if they weren't also a privacy-aware person.
**J:** [Re overlap btwn personas]
**C:** Possibly true [that the differences are sufficient to justify separate personas?]
**C:** Blockchain devs are looking for *any* solution to store data, to simply link data to smart contracts. And IPFS is sort of a tool for that. In the short term, there will be more crypto devs than archivists, eg.
**A:** People with real jobs, getting paid to build smart-contract solutions or travel around and find businesses to build on blockchain [platforms]. IPFS is the default solution.
**C:** Myself, Matt, Raul, and Hector were at Berlin last month doing help desk for IPFS. A lot say "i know i should be using ipfs, but i'm just using (jfps??) right now because it works." They see the overhead as too much, especially for the hackathon sort of [environment where they might be]
**J:** [doh missed it]
**C:** yeah
**J:** If you're given specific case studies, how helpful do you find that?
**A:** On my own tech journies, i first google "does salesforce help define sales territories?" If it says yes, i would see if there's a tutorial. To see how it fits on the difficulty scale. Then i'd kick the tires. Set up a salesforce account, etc, and see if it is [too much trouble, or promising]
**C:** If i'm picking a DB, i'd compare. Does badger do this? Does the other? Which is faster? … This one solves most of the problems, so that's the one.
**J:** If we gave you a grid with supported xyz, would that help you?
**A:** Not that much in our case, bc we would've been smarter to use js at the start. But we knew we wanted to be in Go eventually. … It might'be helped us plan
**C:** More useful for planning than decision making.

### What do you think of how we've captured those personae?

### Are we failing to serve any audiences with these personae?

---

## QRI

### Participants
- Brendan O'Brien

### Tell us about your road to IPFS ...

My first time I heard about ipfs was in a HN post. It sounded cool but my rist thought was that's stupid, that'll never work, but then I went to Data Rescue in Philly and met Matt, a kind and intriguing person who understood the problems we were facing. He was pitching this notion that a lot of our problems were because we didn't have a content addressed internet. THat made me look at the decentralized space again. I'd been working on qri by that point but it wasn't going to be decentralized. it made me realize we had to do t he upfront work to make it decentralized.

Then I looked for docs for both dat and ipfs in a serious way. I came to both of the projecdts knowing what I wanted to do, was vetting both technologies against an agenda. I did some initial tests that allowed me to see if i had an understanding of both of them agt the plumbing level and went with ipfs because it was a single swarm - that made the decision for me. Using the dht. I needed that because at the biz logic level of qri if you take a file not on the dweb and someone else does, there needs to be a hash collision. It's a rare thing but a very important thing when it comes to large graphs of data.

"he wrote his own tests" I'm asking a different question than just "I understand web servers, how does ipfs fit into that". I'm not in the camp of someone who's trying to build a chat app - that's tire kicking. you've learned about a tech and found out it's interesting. My metaphor is more "before there was email" -- we talk a lot about skeumorphism in the UX world because a lot of us learn that way. No one knows what ipfs is yet. If you can speak the language of protocols you can understand the goals behind that project. If you cull through the ways of how people outside of PL describe ipfs on places like HN you'll learn a ton.

The only reason I'm here because the present paradigms don't function for the thing that I want to build. The docs are so abysmal ... the only thing we trust when it comes to IPFS are the source code. Fixing those docs are a herculean effort.

It's only been a viable project in the last 5-6 months. Doing docs before then wouldn't have helped much.

It's not product labs - it's protocol labs. For whom is the target audience of the docs? someone who's intending to use IPFS for in the raw, telling them what they can use for ipfs is more important than "how can I build a chat app?" One is a user and one is a developer. We as the developer side of things is "do we have a clear understanding of how this thing is supposed to work" I can't understand if something is behaving accurately if they don't understand the intent

### What persona(e) did you fit into?

I'm definitely the developer. That's a variation of everything I've been doing. The attribute assessments totally fit me.
Choosing the wrong tools are definitely a fear. Disappearing data a massive fear. The most interesting thing about this intersection of ideology. There's definitely an ideological component to this. VCs say "the internet works, what are you talking about"? I've been trying to pull apart the ideological vs practical purposes distinction so it's nice to see it in the personae.
Maybe use a broader brush for govt corporate slider: are you here for sociotechnological reasons? how much are you here for having a very serious concern for how people behave on the internet?

When you get devs who are showing up - like some projects out of China who just do it because of the firewall - there's a willingness to use and rely on decentralized tech out of a distinct need. Even in the hong kong protests they're using decentralized but it's because they have to and may be able to put up with more as a result.

In time a lot of ideological issues have been replaced by practical means. I'm trying to build a technology that works. If you want to affect change you have to build something that works.

I'm definitely not a privacy aware communicator. My guess is that I've been internally placed in the archivist bucket. Speaking to others in this space I've been referred to as an archivist. Maybe? I feel very little affinity to this one ... one of the biggest betrayals of decentralized tech. The notion of an archivist in a space without any availability guarantees is hard. If that's a target on the goal side we need to do more about that. We've had to build a number of things on our side for archivists to make that a reality.

Our customers are big data power users but we aren't. [If you're building something for those people, would info targeted to your user's problems help?] Twilio is a great example. Seamless.com's customers don't give a care about how they receive text messages. We take the magic of ipfs and our users don't don't want to hear about it. The big data power users don't want to know about how it works, they just want buttons that do it. The folks who want to dig in about ipfs but they don't have time ... in making things easier they obfuscate so much about how it works. When people have a button that works then they come back and want to know about how it works. Then maybe they care about ipfs, but you have to fix the problem first.

Say you google "solve text messages programattically" and you get Twilio. Then you go to their site and you get a bunch of vague stuff on the front page. So then I find some api documentation and I know how to do integrated text messaging stuff. They want to discern what twilio is and is not.

People aren't going to stop from the top down. They don't care that ipfs is the distributed web, they'll get there through a side door halfway down the tree.

### What do you think of how we've captured those personae?

Personally would have seen more bifurcation of the developer persona. I talk to people like this a lot. You have the undergrad comp sci student who's very smart, builds a lot of weekend hack projects but very much "I want to build a chat app" and I send them to js-ipfs. They may not know how to find things but they also have the advantage of youth - they don't get concerned about why something works a particular way. They just start building stuff, they don't question the way someone who needs to make a congnitive jump of someone urunning an http server and trying to find out how it needs to map to ipfs. They need less skeumorphism.

[People who need to map from the centralized space may be at a disadvantage?]

Then you have folks who come from other industries. Reads it, goes yeah it's this, understands it right away. He could suss out the commands that should exist very quickly in order to do the thing he wanted to do.

[Maybe the different levels of dev? People who have breadth of knowledge, plus people who are more equipped to be able to find the thing they want to find very quickly]

Then the more ideologically centered developer who show up because they agree with IPFS. What they often do is that crowd is distinct in that they often write far less code. They might even be closer to the dweb-curious folks. Do you command line? Does git scare you? These may be the webui or companion folks. Maybe they can do bash, ssh into boxes, do github, but you hand them python and a full on programming language and they just say nope, that's not my bag.

### Are we failing to serve any audiences with these personae?

See above ...
Not really a matter of failing to serve anyone. It's still early days. Are we leaving anyone out?

Just qualify your customer. There are folks for whom you can just say "read the manual, you'll thank you later"

I see a real desire for PL folks to turn IPFS into a product as well as a protocol. Things like companion may be a product, but it's still a tool. People don't use companion to browse the dweb, they get things done: I go to reddit to waste time. I know lots of people who download ipfs, pin some stuff, add some stuff and then never use it again. It was an experiment. This is stuff that developers need. It's a product to people like me, but not to the rest of the world. Twilio is a product. But in order to use twilio, you need to need to use curl.

People at IPFS don't always really know what IPFS is. It's not a product. Get over it! I feel like the docs should help explain as quickly as possible. I don't think the archivist is here yet. Someone needs to build a tool to make things for archivists.

For example, the folks that can act as potential release early testers -- this is a different category of devs. That's great, but we also don't want to silo people. We don't want the docs to target us. We're the folks at the bank who have their own account managers. The docs aren't necessarily for us.