Switch thumbnail hosting away from berk.ninja #14

New issue

Closed

opened 2018-05-22 20:54:48 +02:00 by kauffj · 3 comments

kauffj commented

2018-05-22 20:54:48 +02:00

(Migrated from github.com)

This is not a good choice long-term. Ideally it would be spee.ch.

nikooo777 commented

2018-10-03 02:46:33 +02:00

(Migrated from github.com)

I'd like to have a discussion on this.
I disagree that we should use spee.ch for thumbnails, but I agree that we should use a better domain in place of berk.ninja

I can discuss this at the office with Jeremy but my TL;dr would be that if we're not doing it in a completely decentralized way then we should just stick to a centralized solution that we know works fine and will work fine.
using spee.ch would only cause a burden because for each single claim we need a second claim just for the thumbnail, we'd be polluting the blockchain with content that is strictly necessary (possibly considered metadata) of another claim, on top of that, we'd depend on spee.ch being online and working forever (both the domain and the infrastructure) rather than just worrying about the domain and the data being on S3 (easily moved/replaced).

I don't see this solution scaling well and could become a huge problem in the future, so either we bundle the thumbnail with the claim (so that the thumbnail itself is part of the blobs associated) or we use the centralized solution.

edit: this ended up not being a tl;dr....

I'd like to have a discussion on this. I disagree that we should use spee.ch for thumbnails, but I agree that we should use a better domain in place of berk.ninja I can discuss this at the office with Jeremy but my TL;dr would be that if we're not doing it in a completely decentralized way then we should just stick to a centralized solution that we know works fine and will work fine. using spee.ch would only cause a burden because for each single claim we need a second claim just for the thumbnail, we'd be polluting the blockchain with content that is strictly necessary (possibly considered metadata) of another claim, on top of that, we'd depend on spee.ch being online and working forever (both the domain and the infrastructure) rather than just worrying about the domain and the data being on S3 (easily moved/replaced). I don't see this solution scaling well and could become a huge problem in the future, so either we bundle the thumbnail with the claim (so that the thumbnail itself is part of the blobs associated) or we use the centralized solution. edit: this ended up not being a tl;dr....

lyoshenka commented

2018-10-03 15:18:16 +02:00

(Migrated from github.com)

I agree with niko - putting this on spee.ch means we're making two claims for each upload. It also means if spee.ch goes down, all of the thumbnails will break. Are we committed to spee.ch being up with some SLA? I thought we still use it for testing things, running advanced SDK builds, etc.

alyssaoc commented

2018-11-01 19:09:27 +01:00

(Migrated from github.com)

Issue moved to lbryio/ytsync #7 via ZenHub

Issue moved to [lbryio/ytsync #7](https://github.com/lbryio/ytsync/issues/7) via [**ZenHub**](https://www.zenhub.com/)

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: LBRYCommunity/lbry.go#14

No description provided.