Is there any way in which we can check that the setting to use Polygon has taken effect? Nothing changed on the node dashboard 
That would be a great code contribution. Does someone want to try it? Starting point would be here: storj/web/storagenode/src/app/components/WalletArea.vue at 7d5d5552648f26b5abc60cfd6dc5c075b2efa958 · storj/storj · GitHub
Count on it! Will do it later today, thanks for pointing towards it
4 Likes
Any direction on how it should be handled when both zkSync and Polygon are opted it? In that case it would depend on satellite preference if I’m correct?
I don’t know. Maybe display both? Would that work?
The statement from JT was that the order matters but at the moment polygon support is not set in stone so we might still fall back on zkSync at the end.
Now that I think about it, I think it has to be that way since this isn’t a satellite specific area of the dashboard, and different satellites could in the future support different payout methods.
I’ll not step on @odarriba 's toes though. Just preempting a question that might come up to help him along the way.
1 Like
Let’s say a Satellite supports a set of payment methods and the node supports an ordered set of payment methods. What I expect we’d do is take the intersection of the two sets, and then prefer things in the node’s listed order.
4 Likes
Yeah, that would be great, but there could still be community satellites that don’t support the first option. So you may still have different payout options effectively active at the same time. Picking the first option would no longer work.
Ideally it would be based on what the satellites have reported back as the accepted payout option. Then you could base it on what is actually being used by satellites, instead of just what the node operator set. Could still be more than one option if some satellites don’t support your first choice.
And as a bonus: For a prioritized list, if we can’t currently include L1, so it’ll always be lowest priority (fallback). What if I would want zkSync, L1, Polygon in that order?
Derailing this back to the date format discussion, it could be worse. For the last 24 years I’ve primarily been an IBM i (previously AS/400, iSeries, i for Business… @#$%# marketing yahoos) sysadmin/engineer and I’ve had some interesting date formats to deal with when querying files. The default in their OS files was DDMMYY, although possible that could have been altered with a system value. (unsure if it would have just been on displays or actually as stored in the DB records) You can use other date formats (ISO, YYYYMMDD, etc.) for files you build yourself if desired. So if I wanted to sort by year then month then day, the most often needed sort, I had to substring out the field. Then as Y2K approached IBM’s solution was to add a new field to their files for century. 0 if 1900, 1 if 2000. Apparently this was the route that would cause the least headaches for existing code.
And then there is still the looming problem that their YMD, DMY, MDY, and Julian defined date fields that get combined with that century field don’t support dates past 2039.12.31. Unless I change my employer between now and then I don’t think I’ll get to see first hand how that gets resolved. IBM i systems in my shop are set to be retired this year, my duties are shifting to Linux, Windows Server, VMs, storage, and other playpens. It is sad for me actually, I’ve really enjoyed the IBM i platform.
1 Like
Beware the 32 bit Unix Epoch 2038 problem.
Of all the date/time formats Unix Epoch is my favorite. Sorting files by date is simply sorting integers. Time calculations are simple addition and subtraction. There are no crazy strings to deal with, no formatting strangeness… it’s just… Elegant.
2 Likes
For data storage sure… But I don’t think you make appointments with people by saying lets meet up at 1643925600!
2 Likes
Been through this a few times myself with OpenVMS, Solaris and Tru64. OpenVMS was amazing. Our cluster was super stable and used for process control. But it was hard to get developers who knew the platform.
We have already had a couple of 2022 bugs.
Microsoft fixes harebrained Y2K22 Exchange bug that disrupted email worldwide | Ars Technica
1 Like
Oh well, that’s just a matter of getting used to it.
1 Like
How are thing progressing for the polygon trial in early Feb @jtolio ?
I already have one node switch over in anticipation. 
I am anticipating success!
4 Likes