This video explains it well: https://www.youtube.com/watch?v=5Uj6uR3fp-U
Basically IPFS is a protocol, just like how http is protocol. IPFS is meant to create a torrent like network of data. Every piece of data is linked to a hash which identifies that piece of data. Anybody can help host data on the IPFS network. (so that means that people with spare resources like bandwidth or storage can contribute). Using IPFS directly is maybe not the best solution for this. But there MANY (been doing more research the last couple days) platforms that are built ON TOP of IPFS. Such an example is Textile which have a 'bucket' system similar to how Amazon has S3 bucket storage. https://docs.textile.io/buckets/ Because it is decentralised by nature, you don't pay directly for storage. You can however pay companies or individuals (or soon the network itself like a cryptocurrency) to help host those files. But I think with a community aspect like Openstreetmap has, I wouldn't be surprised if there were people who would want to help create this storage pool or system My explanation was simplified but hopefully helps you understand what IPFS has in terms of potential Cheers, Thibault On Thu, 27 Aug 2020 at 12:38, Jake Edmonds via Tagging < tagging@openstreetmap.org> wrote: > Can you elaborate on how IPFS would work? From my understanding, if I add > a file (in this case an image) to my node then a unique address is > generated. But the file is only permanently stored on my node unless > someone else manually pins it on theirs? > > Sent from Jake Edmonds' iPhone > > On 27 Aug 2020, at 12:20, bkil <bkil.hu...@gmail.com> wrote: > > > Then there's OpenTrailView as a viable alternative (neither Mapillary, nor > OpenStreetCam has a free server component), although in the long term, I > think we should follow an IPFS, P2P or federated-systems route to scale > costs. > > I don't feel it's fair to overload Commons by shifting the costs of all of > our street level imagery to them. If we for whatever reason wanted to stick > to a centralized solution, OSMF should be the one paying the costs, but > then we would pay dearly (someone on Reddit did some estimates). > > On Thu, Aug 27, 2020 at 6:59 AM Thibault Molleman < > thibaultmolle...@gmail.com> wrote: > >> - I'm doubtful of the future of openstreetcam >> - some people don't like Facebook to the point where they don't want to >> use mapillary so we need to have an alternative >> >> And that still doesn't solve the problem of not having a system to put >> multiple images into one tag >> >> Cheers >> Thibault >> >> On Thu, Aug 27, 2020, 00:21 bkil <bkil.hu...@gmail.com> wrote: >> >>> Have you considered uploading these to OpenStreetCam, Mapillary or >>> whatever comes after OSM migrates away from that one? >>> >>> On Wed, Aug 26, 2020 at 11:37 PM Martin Koppenhoefer < >>> dieterdre...@gmail.com> wrote: >>> >>>> >>>> >>>> sent from a phone >>>> >>>> > On 26. Aug 2020, at 15:21, Jake Edmonds via Tagging < >>>> tagging@openstreetmap.org> wrote: >>>> > >>>> > Sorry, I meant that images of generic drinking fountains can go in >>>> ‘Drinking fountains in <location>’ and only need one image linked to the >>>> node. >>>> > A unique fountain deserves its own category >>>> >>>> >>>> I named the fountains as an example where I see one image as >>>> sufficient. Of course you could also make tens of each, with details, from >>>> all sides and so on, but for me 1 is completely ok, serves to give an >>>> impression. >>>> >>>> On the other hand, city gates should have at least 2, one from the >>>> outside and one from the inside, in those cases I have recently seen, and >>>> you can’t do it with the image tag (a category for every individual city >>>> gate seems overkill too in many cases). >>>> >>>> Cheers Martin >>>> _______________________________________________ >>>> Tagging mailing list >>>> Tagging@openstreetmap.org >>>> https://lists.openstreetmap.org/listinfo/tagging >>>> >>> _______________________________________________ >>> Tagging mailing list >>> Tagging@openstreetmap.org >>> https://lists.openstreetmap.org/listinfo/tagging >>> >> _______________________________________________ >> Tagging mailing list >> Tagging@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/tagging >> > _______________________________________________ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > > _______________________________________________ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging >
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
