Hello,
In section 6.2 of the whitepaper a short term plan to reduce reliance on a single satellite is mentioned, which would allow users to export/import metadata from/to satellites.
Is there a timeline for when this feature would be implemented? This feature seems crucial to avoid a satellite being a single point of failure!
Thanks
This is already in progress. The satellites are moving from Postgres to Cockroach DB:
This also means no metadata needs to be imported/exported.
That’s great news
So if I have a macaroon with one satellite and it goes down, I’ll be able to use the same macaroon with another satellite? In this case will all funds be shared across all satellites?
Is there any timescale for when these satellites will be available to everyone?
Thanks for the rapid reply 
This is still a work in progress so no official timescale has been mentioned, that I’ve seen.
@jtolio may wish to comment
Ok thanks.
This is very encouraging, as a satellite being a single point of failure is unfortunately a deal breaker for our application 
The metadata import/export would have worked for us, but not as good all satellites sharing metadata by default. Fingers crossed this will be rolled out soon
I don’t think that’s how it would work, but rather these multiregion satellites are hosted over multiple regions themselves and simply won’t go down if a single region goes down.
I’m pretty sure this doesn’t imply you have metadata shared across satellites.
Based on this comment (New us2.tardigrade.io Satellite!) I assumed that metadata would be shared as it’s part of a satellites “application state”? Hoping I’m right but some clarification would be good.
The metadata of satellites is still not shared.
@BrightSilence is right in describing what is mean the cross region for us2 satellite.
@Alexey thanks for clarifying.
In this case are there still plans to add the metadata import/export function to satellites to avoid reliance on a single satellite (and single source of failure)?
This is not one server, it works in several regions. Therefore, you must close all regions, including overseas at the same time. If such an incident happened, I think we would have much more problems than a missed satellite…
However, I sent a message to the team to take a look on this thread.
Ok, thank you.
I would still worry that even with the satellite multi-region and highly available, there may still be single points of failure. E.g. there might be a problem with DNS so the satellite can’t be resolved, or perhaps an error in cockroachDB that makes the satellite state inaccessible from all regions. One real world example of this would be gmail going down late last year.
Without the metadata the files are inaccessible, and if the metadata is only available in one location then it seems to nullify some of the benefits of the underlying storj network.
I can see that as it stands today with only Tardigrade providing Satellites then my points are moot… there is always going to be a single point of failure and that will be Tardigrade. However in the future if independent 3rd parties can run satellites then it would be useful to be able to import/export metadata, and in this way we can avoid relying on a single 3rd party to access files.
Thanks
That’s not true - just because your infrastructure is using multiple regions does not mean it is not a single point of failure. Your whole infra is the “single point”. A single error (e.g. DNS mistake) can take down all tardigrade satellites. This has happened with all major cloud providers at least once (S3 going down for half a day all regions, everything azure going down for 2 hours, etc). So just because you have N servers in M regions, does not fully mitigate single point of failure. If you cannot export metadata from tardigrade into a 3rd party satellite, then tardigrade is the single point of failure. I would appreciate if storj starts being honest around this topic and owns up to that fact.
Hey @pigfrownin the feature you are describing is something we have talked about implementing in the future but it is not currently prioritized very high on our product roadmap. although this feature would increase the ability for users to move from 1 satellite operator to another it does not truly solve what I think you want it to. with “Satellite metadata import/export” it would take a substantial amount of time for a customer to migrate to a new satellite and in that time the satellite that was down would likely be back up again. I think the feature you really want is real-time sharing of metadata across satellites and satellite operators… which is a very hard problem to solve heh
Hi @brandon , real time sharing of metadata across all satellites would be great, but I appreciate if that’s not possible.
I understand what you are saying and think it’s true, for most users it doesn’t matter if they can’t access their files for 20 minutes/whatever, and keeping their own record of metadata and importing/syncing it across all satellites would be a lot of effort for something that will probably happen very rarely, if at all.
However for some users (including myself) the resilience and decentralised nature of the Storj network is the reason why they are interested in Tardigrade. Having a satellite/Tardigrade as a single point of failure, however unlikely, ruins that value proposition. I want to build a product on top of Storj and need to be able to prove to users that their data is accessible even if a % of the network goes down. Since the data is inaccessible without the metadata I can’t honestly say that at the moment.
It’s encouraging that metadata import/export is on the roadmap and I hope it, or some other solution, will get implemented soon.
Thanks