Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Increase dApp Usage Internally #348

Open
pkafei opened this issue Oct 22, 2018 · 3 comments
Open

Increase dApp Usage Internally #348

pkafei opened this issue Oct 22, 2018 · 3 comments

Comments

@pkafei
Copy link
Contributor

pkafei commented Oct 22, 2018

Last month in order to increase dApp adoption, ETHBerlin participants and organizers made a commitment to use more distributed applications (i.e. chats were held on Status as opposed to Slack). Do we think such a commitment would be suitable and/or useful for IPFS?

Background Sources:
ETHBerlin Knowledge Base
If You Liked It Then You Shoulda Put a Dapp on it
Endangered Data

@terichadbourne
Copy link
Contributor

I think this is probably a decision that should be made case-by-case with any specific examples we're considering (Slack v Status, Google Drive v X, etc.). However, in general, I'd encourage us not just to consider the power of dogfooding but also ease of use, onboarding, intended audience, and integrations with other tools. Employees or folks who are already excited about decentralized may be happy to join conversations from dApps rather than more familiar collaboration tools, but if we're talking about newcomers to decentralized or collaborators from outside organizations, a steep learning curve or barrier to entry may prevent them from contributing to the community. There's something to be said for Slack, Google Drive, etc., feeling familiar to a broad range of existing users, who can at least feel comfortable with those collaboration tools while they're exploring the foreign territory of decentralization.

That said, I don't have a good sense of what tools you're considering replacing, and for each, what the audience is and what kind of communication it's used for now. Perhaps you (or others) could share more specific details?

@victorb
Copy link
Member

victorb commented Oct 22, 2018

One first example of "use someone else's vs using ours" is transfering files (obvious huh). I think we're doing somewhat good on this but still many other solutions are being used for passing things around. We should make sure everyone knows exactly how to do this, and figure out the pain-points of doing it, so we can fix it.

Another one is note-taking. We started with hackmd (as far back as I was involved/remember), went over to cryptpad and now we're using Google Docs. The alternative here is PeerPad. If I remember correctly, persistance of notes is the only thing that keeps us from using PeerPad.

Moreso, blogging. I think there has been discussions of moving from our own hosted blog to Medium. In that case, I don't think anything is really missing, it's just that we would get a broader reach with Medium than self-host. There has also been work on a blogging platform on IPFS over at ipfs-shipyard somewhere (@satazor you remember where that work happened?).

Overall, we need to judge the applications based on their features matching with how we use it. If it's just missing one/two features, maybe we can help them implement it somehow.

In the end, the tools should help us. If we have one tool that does what we want, and we have one slightly worse (but not entirely broken) but decentralized, I think we should go with the decentralized one if we can, to force ourselves to see the issues and come up with solutions. But if it's too broken, we should stick with what we have.

@terichadbourne
Copy link
Contributor

terichadbourne commented Oct 22, 2018

@victorbjelkholm, you can find discussion of the platform used to host the upcoming iteration of the blog in this issue, where @mikeal proposes using Ghost rather than Medium: #333

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants