What type of apps would not be a good idea to build on top of IPFS?

[notduncansmith]

For example, would social type apps (Facebook, Twitter) work well, or not well? CRUD apps? What are the challenges associated with transitioning from the current mode of wrapping databases with HTTP?

[jbenet]

The short answer is any. The long answer is it depends on how far you want to go:

1. the easiest thing is static websites. ipfs add -r dir and you're done.
2. the medium thing is to build sites in js that use a wriable gateway (config opt) to add data to ipfs from js. you get to write the datastructure however you want.[1]
3. use an ipfs node in js (impl still forthcoming) to write ipfs objects directly.
4. mount a custom protocol onto the ipfs node to do arbitrary things (like pub/sub, etc).

[1] a good thing to do next is to go through all the "persist object to backend" js frameworks, and make plugins to use ipfs for that instead. this may actually be pretty easy to do now.

[whyrusleeping]

@jbenet he was asking which apps are not well suited for being written on ipfs. But your answer is a good one to the opposite question.

[notduncansmith]

Correct (which made the initial answer "any" a bit discouraging haha)

[jbenet]

Oh, whoops. ^^

[omphalos]

Regarding pub-sub I like to understand how that could work efficiently on top of ipfs. Would someone (@jbenet?) care to elaborate on what that might look like? I would appreciate it.

[whyrusleeping]

@omphalos Hi there! I've been doing some mental work along with @BrendanBenshoof on pubsub through ipfs. I can explain my current thoughts in another issue somewhere else, not sure where best to put that yet. @jbenet thoughts on a good place?

[sonatagreen]

Anything where it needs to be possible to delete data, like Snapchat, can't work on IPFS.

Anything that involves very large amounts of data that doesn't need to be stored forever, like live videoconferencing, would probably be more efficient not using IPFS.

[jbenet]

Anything where it needs to be possible to delete data, like Snapchat, can't work on IPFS.

not exactly-- snapchat isn't actually deleting data. no process in the universe has been found to create self-destroying data. usually it's just a policy that users and software opts to follow. it's -- like all such policies -- circumventable. You could create an app that (a) does not advertize content (hashes are distributed node-to-node or out of band, (b) unpins and deletes content from the local node according to policies. nothing guarantees than a node who got the data isn't actually keeping it, just like snapchat doesn't guarantee it either.

Anything that involves very large amounts of data that doesn't need to be stored forever, like live videoconferencing, would probably be more efficient not using IPFS.

videoconferencing yeah. the large amounts of temporal data, not so much though, because we may actually want to build caches using ipfs that don't pin such data, but do distribute it (or only pin temporarily, etc)

[mixmastamyk]

we may actually want to build caches using ipfs that don't pin such data, but do distribute it (or only pin temporarily, etc)

That's what I'm looking for. Is there a way (currently) to prevent disks from filling up?

[sonatagreen]

You can unpin things you don't want to keep.

[madavieb]

This issue has been moved to https://discuss.ipfs.io/t/what-type-of-apps-would-not-be-a-good-idea-to-build-on-top-of-ipfs/413.