An owner of this repository has limited the ability to comment from new users.

[ghost]

An owner of this repository has limited the ability to comment from new users.

[purplesyringa]

Is there any reason for using modified for your value instead of another name? Based on your username, _last_update should work well (notice that I used _ because that name might collide with some site-specific settings).

[purplesyringa]

where are those site specific settings?

I mean, some sites (e.g. ZeroTalk and Git Center) use content.json to store their settings there.

[purplesyringa]

I'm using other timestamps along with the basic POSIX of what is shipped with ZeroNet

Hm, if you're using POSIX timestamp already, can you maintain both modified and _my_fancy_modified? This will allow your modification to be ZeroNet-compatible. I also don't see any problems with this.

I also get rid of the zeronet_version from content.json for a very good reason.

Can you elaborate please? AFAIK we don't use it but it might be a good way to monitor how people update.

[purplesyringa]

Also, modified is used directly for p2p communication to spread user file updates. Replacing it will most likely render ZeroNet unusable.

[purplesyringa]

That's is fine @imachug since I don't use any of those...

So are you going to make a private-use ZeroNet fork? I guess it's fine then.

If you send the version number may someone will come up with a ZeroDay or just come to GitHub check the issues and will attack people who has a specific version...

Not really. Trial-and-error would work as well even if we didn't send version.

[purplesyringa]

and again is unethical to monitor those numbers by you or anyone else!

But why? It's quite useful for development, isn't it? We send the version in p2p protocol but I don't know why it's used in content.json actually. @HelloZeroNet Is there a reason?

[purplesyringa]

I found no problem until now.

You're probably going to notice it later, lol. Currently listModified p2p command accesses ContentDb to get modified property, and that one is filled from content.json. Thinking more about that, you might be able to use either of these solutions:

• Either leave modified as-is and add your own property;
• If you want to change the way files are checked / downloaded, replace modified with something like version number (i.e. something that increases every time a change is made) and possible also use another property for version metadata or something;
• Another way is to replace modified with your own object and modify half of ZeroNet code to parse that value correctly.

I don't understand what your usecase is. I think that option 2 will work for you but if it doesn't, I would need some more information to help you. You can publish it here or to imachug@gmail.com if you want to keep it secret.

[purplesyringa]

Actually, it is UTC time as per this SO answer. I am not sure why json.dumps provides incorrect results, let me take a look.

[purplesyringa]

That SO answer was just to explain that time.time() returns UTC time (at least on common OSes).

[purplesyringa]

Actually you haven't replaced all "modified" instances, e.g. here:

                    sign_content = sign_content.replace(
                        '"modified": %s' % repr(modified),
                        '"modified": %s' % modified_fixed
                    )

Make sure to fix those as well.

[purplesyringa]

modified_fixed stands for "recovered" or something like that here. Some Python implementations might give slightly incorrect results so ZeroNet fixes them.

[purplesyringa]

TBH I don't see any reason for any additional quotes

[ghost]

I agree with @imachug . I don't see any reason for doing that either.

[purplesyringa]

You mean incorrect timestamp?

The timestamp was mostly correct, but it could be off by one or two digits because that's how floating arithmetic works.

[ghost]

@zeronettimemachine Since you've opened an open issue, then it's meant for public discussion ;)

Also, since we're working on relicensing the project, accepting new contributions may be a legal problem, at least until we resolve the licensing conflict. I'd advise to wait a few days until we settle on it.

[purplesyringa]

Why's that? How is this new format better than POSIX timestamp?

[ghost]

@imachug I agree. Creating new formats for the sole purpose of making them is both troublesome and increasing chances for a new security bug.

@zeronettimemachine Yes, please share your point of view with us.

[ghost]

OK, but why do you think that this may improve stability? What kind of time conflict could this prevent?