? Editing: Post:21.body Save Delete Cancel
Initial sync in progress...

Newest topics

Follow in NewsfeedFollowing
+ Start new topic


^1 ^2 added ━ started by user_name
More topics


Follow in NewsfeedFollowing


^? ^0 username posted added
Please sign innew comment
Sign in as...
Submit comment
You are running out of your allowed space, please contact the site's admin at unknown to raise your limit.
user_nameadded ^1 ^2
gonggongon Feb 26, 2019 ^1 ^2

another public id i've found:

publicalityon Dec 08, 2018 ^1 ^2

So when i switch on Multiple users plugin, my account doesnt work @.@ even though I didn't mess with the seeds or keys yet

thunderarchiveon Jun 05, 2018 ^1 ^2

anonymouslogin: How can we anonymouslogin have several different ZeroMe accounts?123

diffrent hubs

james007on Apr 16, 2018 ^1 ^2

This is good. We need more of this. BugMeNot for ZeroNet.

kaffieon May 24, 2017 ^1 ^2

I have noticed that this method fails to propagate posts made by a new user auth_key, but appears to be able propagate posts to those user auth_keys which have previously been propagated. Quite the question as to how initial posting works; perhaps a filter searches for the auth_key first, and if found doesn't trigger creation function, while said creation function does not recognize anything other than the certSelect API call's array of accepted cert issuers. Something to poke later.

Yeah I just ran into this same bug. After doing some digging it appears to me that it's due to the modified name being listed as the cert signer. There's a field in the user's content.json which looks like this: "cert_user_id": "kaffie@zeroid.bit",. When the first description field is modified as in your example, when creating a new content.json it writes it as "kaffie@modifiedname". This then leads to a problem as zeronet checks the site's content.json for this:

  "cert_signers": {
   "kaffie.bit": [
   "zeroid.bit": [

Which links the @whatever.bit to an actual address. This, of course, is yet another reason why names should not be used for unique identifiers. @nofish: needs to really fix these bugs and rely only on unique public keys instead of various domain names/user names/etc. The actual cert itself contains no information as to which site actually signed it. That's a huge problem. Ideally the cert should contain the address of the signing site, which is included in the content.json for the user. Then this sign+site address should be used to verify that it's legitimate and in the valid list of site signers.

Lots of problems unfortunately.

This page is a snapshot of ZeroNet. Start your own ZeroNet for complete experience. Learn More