Quite a bit of posts since I last checked in so I'll catch up on the thread later but for this question in particular https will be added later, it's not an issue to add, but where it might be an issue though is for example when we allow a user to define using an alternate IPFS gateway to the ones we provide which suppose you want to use http://ipfs.foobar.com which doesn't have support https, this may cause issues in the form of mixed content.

It's something we'll have to look into and run some tests for as I know in the past with web development I've ran into issues with mixed content.

Hello,

Twitter bounties have been issued directly to the accounts of those who participated, registered and passed our audit. Some people may even notice a small bonus in comparison to what they're expecting. A total of 64,000 VIDZ was paid out to participants (0.256 BTC at current market value of 400 sats). The OP has been updated with development fund expenditures.

In the future, we may consider running another Twitter campaign when we're ready with some upcoming changes we're working on. Currently we're working on integrating the UI that Dynamic Index has developed as well as a public api with documentation for 3rd party developers to programmatically interact with the site.

With the adoption of our platform as it grows what does an api bring to the table for the typical consumer? The short answer is more content! With the ability to programmatically automate content, 3rd party developers will have the ability to create scripts to do quick multi-uploading or even a more complex task such as downloading a torrent and on completion automatically seeding it to the IPFS network and uploading the hash onto our index.

Currently, we are estimating to have things released on February 15th but this date may be adjusted.
Thanks for your patience and support as always!

The site runs on user submissions. We do not host any of the media files nor do we submit them.


I suggest reading the whitepaper. The currency is used for a large number of things throughout the site and the blockchain will be used for various backend site features to maintain data in case of a catastrophic failure or seizure of servers (routing to new domain, backing up magnet links/ipfs hashes, etc)


We are already experimenting with various subtitle implementations and they work just fine but subtitles are not part of the initial scope of our project. Here's the technical hurdle to support it across all media files....

1: Html5 <video> tag supports the VTT format for subtitles. We have tested converting some SRT subtitles to VTT and incorporating into the site. They work properly and of course have no issue.
2: There are multiple APIs to locate subtitles in various languages for media files but VTT is not a traditionally used format so every language for every subtitle would need to be downloaded and converted by our servers and then linked to each media item.


Adding subtitles is easy, we've done it and it's not a difficult thing to do. The problem is that to go from 'subtitles work' to 'subtitles exist for everything' we would need to be hosting the subtitles ourselves and running batch conversions on them. Hosting the subtitle files ourselves is a legal grey area (edging closer to a blaring red alarm) and so the solution is to use IPFS to host the subtitle files. We're fine with doing that but given users would have to locate the correct subtitle files, convert them, add to IPFS and then link to items, that is not exactly an elegant solution.

Short version: There is no simple, legal, stable, user friendly solution to add subtitles to the project in its current state. We've done the dev work and experiments to make sure its possible but it is simply not a priority of the site at the moment.



Users are able to add content in whatever language they want. I believe I saw a foreign film added to the site yesterday although I cannot remember the name of it. We are currently encouraging users to stick to english content until the new version of the site is finished so that at that time we can add user custom tags so they can tag things in the uploaded language to help people find what they are looking for better.


User tags are something we will be enabling following the new site theme rollout in mid february and will allow people to add much more narrowly focused tags


Adult material will not be permitted on the PureVidz site as it needs to be family friendly and accessible to people of all ages and preferences. We are open to the idea of rolling out a subdomain such as xxx.purevidz.net in the future but it is not part of the scope of this project.

Currently we are doing a rough load balancing system to improve redundancy and to run some internal tests. When a file is requested you are assigned to a random IPFS node (this distributes the requests across all nodes added to the network) but if the file does not start playing within 10 seconds it will switch to a different node (it assumes that the node being used is either too busy to serve the file at a satisfactory speed or else it is offline for some unforseen reason).

This is not something we plan to do permanently but rather something that allows our site to track node uptime and balance out requests across all nodes added. Moving forward we will be rolling out a much more comprehensive load balancing system which will cache 'known' nodes to forward you to the best node for the file you're requesting to make sure it is served quickly and reliably. Consider the current settings to be a debug mode for us to gather data.

Nodes in IPFS act much like a tracker does with torrents. When you request a hash from a node, it checks for parts of that file within peers (users and other nodes connected to it) and then serves it to you. Pushing all users to a single node would NOT be decentralized and is what we want to avoid. Instead we are running some of our own nodes, adding nodes run by our users and contacting existing ipfs nodes to ask if they are willing to join in our site. So far the response has been very good but we are still focusing on the underlying stability of the system rather than pushing for it to function at optimal speeds. Better to work kinks out now than when the site has grown and has thousands or millions of people trying to view items.

Likes dislikes and total views are part of the most recent update to the site. As the system evolves and improves we will be looking to integrate these stats more directly into the service - that will be part of the UI update coming in mid Feb though as we need to give the site time to populate the data before we use it for anything more than raw stats.


Subtitles are not part of the scope of the initial project but is still something we are looking to tackle. HTML5 <Video> tag only supports WebVTT subtitles which provides a barrier for us natively supporting them for all items. We are looking at options for how to tackle that but it is not something I would expect us to work on before the full 1.0 release of the site. Subtitles will primarily become important with foreign movie and anime series support which has the added issue of having less sources to pull accurate metadata from (title, description, air date, etc)

We will be adding referral systems to the site at the same time as we launch the new interface (looking at mid february). Given the site is still in beta and issues should be expected, we want to avoid introducing advertisements that will need to be re-structured anyways when the site is redesigned with the new template.





You can find quite a bit on our financial plans in our whitepaper or throughout the thread. VPN referrals, targeted (non intrusive advertisements) and product partnerships are the main tools we are looking at in addition to how the currency will be used in the site.

We are currently only approving IPFS submissions as that is the system we are currently testing and is performing the best.

The issue we were having with WebTorrents is that the adoption of the protocol into the most popular torrent clients such as uTorrent has not yet happened so if you are submitting torrent files make sure you are also seeding it with a webrtc compatible torrent client such as WebTorrent-Desktop or Vuze. People are still welcome to submit WebTorrent releases and we will review and add them to the site but right now our focus in on making sure the recent addition of IPFS is fast, reliable and scales well to hundreds/thousands of items. Once we are satisfied that IPFS is performing well then we will be re-enabling approval of webtorrent based items.


At the moment we are only approving IPFS additions but that will soon change. Keep in mind that torrents and IPFS function very much the same in terms of p2p distribution and connections. As such, well so we strongly recommend using a VPN if you are in a country with more strict copyright laws.


<edit>

I just took a peek and it seems we have over 90 movies approved on the site since the switch to ipfs! Very happy to see so many people adopting the new protocol! As promised earlier in the thread, as we finish doing our ipfs integration tests and looking for possible flaws in the system, we will then be posting a full tutorial on how to set up your own IPFS node!

It's PoS.

I'll try to address this clearly for people for those asking, the meta data and tagging has been done for some time now and will be improved. This is essentially the feature when you search the movie/TV title and it fills in all that information for you (Synopsis, Genres, etc). There are some current limitations with this like I previously mentioned. An example of this is current the auto populate doesn't work well for great for currently airing anime which is a big form of media, but does work well for main stream/English TV and movies. Better support for this can be added in the future, but for the time being it does it's job fairly well. Video suggestions by similar tags is a system that's long been implemented as well, it's clear to see it's working as there are some recommended movies at the bottom of viewing one. Playlist management is done, but isn't entirely visible in the current UI since we've temporarily disabled TV while we add support for TV through IPFS. There are two examples of this which is a playlist could be derived from a users liked content (new) but more important playlists were auto-assembled when a user uploaded a season. A season was essentially a playlist which was a collection of several entries. Rather then spending development time making pages for and writing the front end integration for certain features on the current UI which can be a lengthy process, we've chose to focus on other important matters because we're going to be switching to the front end Dynamic Index developed. Lastly, subscriptions, again this is done but there's some issues with this in the current UI. For example, suppose you like someones content very similar to how when you're on said content it has recommendations you can perform an analysis on content they've liked and suggest other content from that user which is a good starting point. On Youtube you see this feature as "You might also like from this User..." which just limits the related algorithm to content from that user then content entirely on the index. The other issue with subscriptions is that currently all views are uploaded anonymous. We planned on addressing this again in the new UI where a user chooses certain permissions when uploading a video. It's currently not like Youtube in the sense that you see who uploaded it and they have a channel and you can see their other uploads etc the reason being it requires UI for the user profile.

There seems to be a disjoint in thinking between practically and what's best for PureVIdz versus what gets us paid. Hypothetically speaking, we had never mentioned IPFS or a new UI before on the roadmap so should we just scrap those and prioritize what gets us paid because those are our tangible incentives? The obvious answer is no. Here's another hypothetical, during the crowdfunding process should we have made promises for things that would take years to develop but still collect our crowdfunding money upfront after the token/coin launches like every other crowdfund does? The obvious answer is no, because anyone doing this makes the whole point of escrows pointless and if that was their intentions from the start there was no reason to use an escrow other than for show purposes. We should be prioritizing development in a way that lets us grow and expand the platform in the fastest way possible and lets people feel an immediate product that still works quite well even if it's not to the point we intend to eventually get it to. Our incentive to get PureVidz to that point is that the faster we're at the point where we can approach main stream users and grow our reach the faster we all benefit.

Thanks.

Hey everybody,

Soon we'll be performing an update which will add new features to PureVidz and prepare us for our upcoming changes once we're ready to integrate the UI Dynamic Index has been developing.

The functionality for favoriting which is a specialized version of playlists will be available in the new UI. The main reason for this is pragmatically speaking while the behind the scenes work is done there's no reason for us to waste time developing this on top of the current UI layout when we could be working on more important things. For example, our next major update will include the public api which enables people to write scripts that automate adding content to our index as well as the new UI. At this time with Dynamic Index's current progress we're anticipating the new UI and api update will be ready by some time in mid February. After this release we will be working on the introduction of VIDZ based features to facilitate the VIDZ ecosystem.

In the next 24 hours, the site will be updated to show some of the new information we've added such as showing the total views on videos, likes/dislikes (must be logged in) and within the next 48 hours we'll be adding a new IPFS gateway server to our collection to help improve the quality speed and maintenance of IPFS based content.

We're current in the process of setting up a signature campaign where mexxer-2 will be our manager and we'll be requesting Dabs as our escrow. Once this is ready we'll post another update. Please remember if you participated in the previous Twitter campaign fill out your information at http://purevidz.net/Dashboard/Twitter as the deadline is soon approaching.

Thanks and there should be no significant interruptions during our maintenance.

Thanks to coinexchange.io for adding us


Domain seizing isn't an issue nor does any form of our plan require Twitter after all this isn't an issue for even centralized streaming website, TPB, etc. If Twitter were to ban us, that's unfortunate but doesn't affect any of our model. I've mentioned before, there are actually easier ways to go about doing what you've mentioned then directly needing to store the information on the blockchain while still retaining decentralization through IPFS and it's hard to say at this time what route we'll go but most likely answer is a hybrid solution (leveraging both IPFS and blockchain) as that's always been our approach; To get the best out of whatever said technology has to offer and this was part of the reason we did early integration for IPFS.

The ideal goal is to work towards something you described where the entire product can function without intervention but one step at a time. Looking at things from a practical point of view, a semi-centralized product isn't a bad thing in comparison to other projects where they say "thanks for your money, now give us 2 years to develop the product" and you're left biting your nails wondering if they're actually making any progress since you can't see but more importantly feel that progress.

In short, what you've described is possible but will take time.

It's not something we've had to time to heavily look into so the current answer is no. I mentioned them because another user said he had a working test/example using MKV files so I asked him to forward me his test data/sample as it would speed things up on our end.

If you're wondering why MKV/non MP4 files are a headache it's because in HTML5 when videos became a standard to the browser, the standard was also that it needed to have a specific video encoding and specific audio encoding (h264 aac). For a long time before videos were natively supported in the browser Flash which is a browser plugin was used as a hack to circumvent this but it meant videos needed to be converted to FLV.

Manually auditing all those hashes and adding them would really be going out of your way especially with no easy way at this point in time of determining which hashes are used by the site. The same argument you made can be made for any content being served through IPFS that's taking up a lot of bandwidth. It's not a single point of failure, we're running nodes to assist the IPFS network your argument makes the assumption the entire network complies to this mindset of "I haven no incentive to seed these files so let me go out of my way to blacklist them" which is literally the opposite of what IPFS stands for. There's a reason why for example ipfs.pics's gateway for example will still serve you non-image content if you request it... because that's what it's suppose to do.

It came from one IP address because it comes from the gateway server, the gateway server is the one that interacted with many other network nodes to assemble the file blocks. If you inspect the javascript on one of our pages right now we have statically added one IPFS gateway because while we could use other public nodes like ipfs.pics's we know that's not what the intend it to be used for and adhere out of courtesy. We'll be adding more nodes to this list and we'll be adding the functionality to set a preferential IPFS server in your user profile so rather than being served from one of ours, you can set your own.

You should check out the IPFS subreddit, the legalities of running a gateway has been discussed quite a bit on there.

I think you've misunderstood. As we mentioned IPFS is intended to be another streaming method that we've introduced to the platform, content can now be added in the form of a WebTorrent magnet link or an IPFS hash. Secondly, one would have to go awfully far out of their way to blacklist content used entirely on our site specifically because there's no single point of origin. While someone yes might choose to blacklist our gateway, this wouldn't affect our services heavily.

We're not so brazen to think "lets use everyone else as a crutch." We'll be setting up several nodes to be used as IPFS gateways and heavily contribute towards open and public IPFS gateways. Our own nodes will bootstrap off one another and pin each others content, whatever it may be.

Again, I wouldn't word it as we've moved to IPFS but rather it's now another form of uploading content we support. I mentioned before, there's also a lot very cool things IPFS brings to the table like for example dumping our index to a json file regularly, hosting it on IPFS and creating a simple decentralized search index. It's brought a lot of potential to light.

IPFS implementation itself is finished but has not been enabled for TV shows yet as they function somewhat different with our current setup.

When submitting a ipfs hash instead of a magnet link, the proper format is ipfs:{hash}. We will be offering full tutorials on how to set up your own ipfs node for those who are interested in seeding content in the coming days. Right now our priority is getting support for TV shows added and continuing to test the stability and scalability of the new setup.

Following the completion of the new web template currently in progress we will be re-designing site functionality to better match the dual webtorrent/ipfs functionality we now offer and to make sure we have plenty of tutorials in place for those who want to submit items.

Thankfully we've already had a number of our submitters start testing the ipfs system and it's working really well so far. Load times for files are generally 5 seconds right now which is a HUGE boost compared to the average speed of webtorrents.


Before anyone panics, we still support web torrent content and will continue to do so but until the technology is adopted by more well established torrent clients (uTorrent being the biggest example), its speed is simply not where it needs to be to roll out the 1.0 version of our site. IPFS offers all the same benefits while also being in our opinion the better technology.

IPFS is performing incredibly well in our tests so far! The biggest hurdle will be discussing the new system with those who have been uploading content to our site. Assuming we can walk them through the process of using the improved system it will spell huge stability and speed improvements for the project.

We are working on a full site re-design so when the new art and theme is complete we will be updating all references on the site to reference the hybrid support we now offer of webtorrents AND ipfs. We do not plan to abandon webtorrents by any means but there were just too many issues with slower speeds to justify the site running exclusively on the technology. As the web torrent protocol grows and is adopted by more torrent client we expect that it will catch up to ipfs in terms of stability and speed and since we already support it, that's a huge benefit for everyone involved!

We've already heard back from a few of those who were submitting content to the site. Based on what they are saying, we should see quite a bit more content joining the IPFS based test in the coming days.

I'm going to assume you're talking about IPFS since I'm sure most people understand how torrents work. Anyways, this is a bit difficult to explain without going into super technical detail so I'll try to make this as simple as possible.

When you request a file i.e. refer to my 3 example links in the post above which references 3 different gateway servers but the exact same file (hash) first the gateway node tries to resolve the file, so it looks for other nodes who have shredded blocks of the file. The gateway node then reassembles the file and serves it to the person trying to reach it and the content is temporarily stored.

Suppose you're running an IPFS node yourself, and content you add to the network yourself is by default pinned to your node which means you will keep seeding it so long as you're running your IPFS node and don't unpin it. Content that isn't yours will be kept for a temporary time frame. If after said given time frame there are no requests for the file and from that gateway it will purge the blocks to free disk space. If the file is re-requested after purging, the gateway node will then again try to retrieve the blocks from some other node.

Essentially as it works with torrents, as long as one node is continuing to seed the content or in the case of IPFS the content is being regularly requested it is then available to the rest of the network.


I've mentioned before, the top 2 are the ICO address where people still have coins on that haven't been withdrawn and the development fund. The 35kk is sale bought VIDZ yet to be withdrawn and the 23kk is the dev fund.

Later on some time after the introduction to VIDZ being used on the site, you'll be able to create bounties yourself to have a movie uploaded/subbed in the language of your choice. The content that is uploaded is purely by choice of the uploaders right now since there is no major incentive at this time to upload other than "being apart of the community."

Think of it the same courtesy that is shown when torrent users download a movie and continue to seed it for a few days after they've enjoyed it so others can enjoy it too.

The site is back online, but we're still conducting maintainence based activities.

The first thing to note is there's a reduction in content, there's less movies and TV is currently unavailable. This is due to the fact we're yet to add IPFS support for a full season being uploaded over IPFS which will be done in the next day or two. Now that the update is complete, we would fairly assume as our uploaders come online and take notice things will resume as normal.

Another thing we're aware of that need not be pointed out is the site still calls everything a "Torrent" for example "PlayTorrent", "ManageTorrent", etc. This will remain this way until the new UI is finished being developed. We see no reason to waste resources in doing heavy overhaul on the current UI when it's simply going to be replaced anyways in a few weeks.

Please be patient, in the next few days we'll be introducing some more standard features to the site such as favoriting, liking/disliking videos, view count, etc.

In mid-february we're anticipating to have our public API released where an uploader will be able to automate their content addition to our site. Of course, the moderating process still needs to be done manually though

Thanks for your support as always, especially those that have worked with us through this change and have been providing content for the site.

It's hard to say, but from my testing of IPFS we really like the potential we're seeing especially for example with creating decentralized dumps of our database/index.

I'd actually argue using IPFS has been more "clean" then WebTorrents and this is primarily due to lack of adoption at this time in the torrenting community. WebTorrent clients are a fairly new thing and most people are still running legacy clients so finding torrents with a high amount of WebTorrent seeders is harder then just finding traditional seeders.

There are some other neat project I ran into is http://ipfs.pics which is similar to a distributed imgur. It's quite annoying when an image host up and disappears. I remember a long time ago having tons of images in old forum posts on image shack and then when they purged all those images were lost too most of which I didn't have back ups of.

I haven't had much indepth testing with MKV other then the hour or two I spent tinkering with it. If you could neatly compile your test results ie upload your mkv file to a host you can hot link it, or even put it on IPFS or something and then PM me a link to a HTML file that can play it would be of great help and speed things up on our end if there was an explicit example rather then us needing to tinker with libraries and plugins like videojs and videojs-vlc.

We only disabled the main loading page, the rest of the site was still acessible but we wanted to make it clear that some content would be broken while we were doing our matainence.

At this time no, but it's possible to do this by storing the hash in the arbitrary data field of a bitcoin transaction and likewise a VIDZ transaction.

However, given our adoption of IPFS there's a lot cooler and user friendly things we can do. For example example, we could have a bot that dumps our database index of magnet links an IPFS hashes in json, csv or even a neatly formatted HTML page/table and then propogate it over IPFS. A link to this could be made available on our website or even automatically tweeted to combat censorship.

There's plenty of ways we can go about this really and we haven't decided on any particular one yet. At this time, we're still considering how we can best leverage the technologies available to us.


We're not hosting any content ourselves. Torrents are downloaded through WebRTC and WebTorrent based clients. IPFS is a... well interplanetary file system.

Lets take for example the file o48o tried to troll us with, and yes, you got me:
https://ipfs.io/ipfs/QmcniBv7UQ4gGPQQW2BwbD4ZZHzN3o3tPuNLZCbBchd1zh

This file is also accessible on our gateway:
http://ipfs2.purevidz.net:8080/ipfs/QmcniBv7UQ4gGPQQW2BwbD4ZZHzN3o3tPuNLZCbBchd1zh

And also available on the ipfs.pics gateway:
http://ipfs.pics/ipfs/QmcniBv7UQ4gGPQQW2BwbD4ZZHzN3o3tPuNLZCbBchd1zh

As long as you have the file hash, you can access it on any IPFS gateway. It's quite amazing.

Our goal is to have everything back online tomorrow with support for IPFS added. This will not be a visible change to users of the site (except for submitting new media) and will result in media loading and playing much faster than the old site. We still fully support webtorrents but are looking into the alternative p2p delivery system due to its increased reliability, scalability and responsiveness.

With webtorrents it generally took 10-30 seconds for a video to play. With IPFS we are looking at 1-10 seconds in most cases with less issues of dead links.


As mentioned earlier in the thread, we will also be looking into other p2p distribution methods so that as technology advances, our site will function fully with as many relevant technologies as possible. These improvements will NOT change how the site functions but rather making it easier for the site to grow with our userbase.