Hi there, I rebuild atlas.torproject.org using Ember.js instead of Backbone. It looks like this right now:
search page: http://i.imgur.com/GEM86mk.png details page: http://i.imgur.com/1UwpwlA.png
I'd like to share the code and thought about putting it on github but I don't know if it's ok for you with all the Tor assets (tor logo).
Would love to hear what you think about it.
thank you
Hi,
Nice work! Please publish it, but better remove the Tor logo: It makes it look like an official project, and Torproject receives a lot of support requests for third-party projects that either use the Tor logo or use "Tor" in the name.
Apart from that, legally, using the logo like this is likely a trademark violation. To keep the trademark, no matter how good or well-meant the project is, Torproject /has/ to enforce it -- otherwise it could lose the trademark. :-(
Am 2013-06-25 06:02, schrieb Moritz Bartl:
Hi,
Nice work! Please publish it, but better remove the Tor logo: It makes it look like an official project, and Torproject receives a lot of support requests for third-party projects that either use the Tor logo or use "Tor" in the name.
Apart from that, legally, using the logo like this is likely a trademark violation. To keep the trademark, no matter how good or well-meant the project is, Torproject /has/ to enforce it -- otherwise it could lose the trademark. :-(
I removed the Tor logo. It still use "Tor" as part of "Tor Relay Search" because i don't know if there is another word to describe what it does.
screenshot: http://i.imgur.com/dYU8IBk.png
Is it ok like this?
On 26.06.2013 07:40, me@rndm.de wrote:
I removed the Tor logo. It still use "Tor" as part of "Tor Relay Search" because i don't know if there is another word to describe what it does.
screenshot: http://i.imgur.com/dYU8IBk.png
Is it ok like this?
I cannot speak for TorProject Inc., but I would say yes, it is. To be even safer, you could add a small disclaimer at the end of the page:
Tor Relay Search [or whatever] is not affiliated with the Tor project. "Tor" and the "Onion Logo" are registered trademarks of The Tor Project, Inc.
On 6/25/13 9:00 AM, me@rndm.de wrote:
Hi there, I rebuild atlas.torproject.org using Ember.js instead of Backbone. It looks like this right now:
search page: http://i.imgur.com/GEM86mk.png details page: http://i.imgur.com/1UwpwlA.png
I'd like to share the code and thought about putting it on github but I don't know if it's ok for you with all the Tor assets (tor logo).
I agree with Moritz' concerns about the Tor logo, but it seems your new solution addresses those quite well.
Would love to hear what you think about it.
Nice work! A few comments/questions below:
- I have to admit, I don't know much about the various JavaScript libraries/frameworks, so I don't know about pros and cons of using Backbone or angular.js or Ember.js. Can you say why you chose Ember.js over the others?
- Is this an Atlas fork or a rewrite? Are you planning to contribute your changes to Atlas, or do you want to run this as a new project? In the former case, please be sure to talk to Arturo or Sathya (both are on this list). In the latter case, please let me know when your tool is deployed, and I'll keep you posted about future Onionoo procotol changes.
- Are you interested in enhancing Atlas or your tool even more? There are quite a few tickets open, where #6320 seems most urgent: https://trac.torproject.org/projects/tor/query?component=Atlas&status=!c...
Thanks! Karsten
- Is this an Atlas fork or a rewrite? Are you planning to contribute
your changes to Atlas, or do you want to run this as a new project? In the former case, please be sure to talk to Arturo or Sathya (both are on this list). In the latter case, please let me know when your tool is deployed, and I'll keep you posted about future Onionoo procotol changes.
I don't know if you could call it a fork. The only part i used was the d3.js rendering part because i never really worked with that before. I never had the opportunity to work on a Backbone project so I don't know if is useful if i contribute to it without having knowledge about backbone best practices.
- Are you interested in enhancing Atlas or your tool even more? There
are quite a few tickets open, where #6320 seems most urgent: https://trac.torproject.org/projects/tor/query?component=Atlas&status=!c...
Thanks, I'm going to look into. :) I implemented the sha1 hashed fingerprints in the ember version. It's really easy using jsSHA.js (https://github.com/Caligatio/jsSHA/tree/release-1.42). Here is my implementation: https://github.com/makepanic/emberjs-tor-onionoo/blob/master/public/js/helpe...
btw i released it on github some minutes ago. The source is available here: https://github.com/makepanic/emberjs-tor-onionoo And a live version via github-pages here: http://makepanic.github.io/emberjs-tor-onionoo/
If there is anything wrong with the name or Tor mention please tell me.
On 6/29/13 7:19 PM, me@rndm.de wrote:
- Is this an Atlas fork or a rewrite? Are you planning to contribute
your changes to Atlas, or do you want to run this as a new project? In the former case, please be sure to talk to Arturo or Sathya (both are on this list). In the latter case, please let me know when your tool is deployed, and I'll keep you posted about future Onionoo procotol changes.
I don't know if you could call it a fork. The only part i used was the d3.js rendering part because i never really worked with that before. I never had the opportunity to work on a Backbone project so I don't know if is useful if i contribute to it without having knowledge about backbone best practices.
Sounds like a rewrite then. That's fine! One idea behind splitting up Tor status websites into a data providing part (Onionoo) and a data presenting part (Atlas, Compass) was that it's supposed to be easy to replace either part. Happy to see this happening here! (Will keep you posted about future Onionoo protocol changes.)
- Are you interested in enhancing Atlas or your tool even more? There
are quite a few tickets open, where #6320 seems most urgent: https://trac.torproject.org/projects/tor/query?component=Atlas&status=!c...
Thanks, I'm going to look into. :) I implemented the sha1 hashed fingerprints in the ember version. It's really easy using jsSHA.js (https://github.com/Caligatio/jsSHA/tree/release-1.42). Here is my implementation: https://github.com/makepanic/emberjs-tor-onionoo/blob/master/public/js/helpe...
Okay. Looking forward to seeing your tool display Onionoo's bridge details!
btw i released it on github some minutes ago. The source is available here: https://github.com/makepanic/emberjs-tor-onionoo And a live version via github-pages here: http://makepanic.github.io/emberjs-tor-onionoo/
That's pretty neat! I just opened two minor issues.
If there is anything wrong with the name or Tor mention please tell me.
Nothing wrong from a legal perspective (IANAL), but Tor Onionoo Search isn't as catchy as it could be. Hmm, how about picking one of Atlas' children's names (http://en.wikipedia.org/wiki/Atlas_%28mythology%29) for your project? Greek mythology is full of fun project names.
In any case, you should tell tor-talk@lists.torproject.org about your project, probably in a new thread.
This also sounds like a fine project to mention in the first issue of Tor Weekly News. Feel free to add a paragraph there:
https://trac.torproject.org/projects/tor/wiki/TorWeeklyNews/2013/0
Great stuff!
Best, Karsten
Okay. Looking forward to seeing your tool display Onionoo's bridge details!
I updated it to display bridge detail and enable bridge search. Works fine so far. You can now toggle between relays or bridges in the search results.
Nothing wrong from a legal perspective (IANAL), but Tor Onionoo Search isn't as catchy as it could be. Hmm, how about picking one of Atlas' children's names (http://en.wikipedia.org/wiki/Atlas_%28mythology%29) for your project? Greek mythology is full of fun project names.
Mh I started to look into some names but haven't found a fitting one. If anyone got any suggestion i would appreciate it.
btw. is there data (bandwidth or something else) that is really important for a Atlas user when viewing a detail page or is everything equally important?
On 7/3/13 5:16 PM, me@rndm.de wrote:
Okay. Looking forward to seeing your tool display Onionoo's bridge details!
I updated it to display bridge detail and enable bridge search. Works fine so far. You can now toggle between relays or bridges in the search results.
This is awesome! Repeating the link here, so that others can follow:
http://makepanic.github.io/emberjs-tor-onionoo/#/
Nothing wrong from a legal perspective (IANAL), but Tor Onionoo Search isn't as catchy as it could be. Hmm, how about picking one of Atlas' children's names (http://en.wikipedia.org/wiki/Atlas_%28mythology%29) for your project? Greek mythology is full of fun project names.
Mh I started to look into some names but haven't found a fitting one. If anyone got any suggestion i would appreciate it.
How about "Globe" or "Globus"?
btw. is there data (bandwidth or something else) that is really important for a Atlas user when viewing a detail page or is everything equally important?
That's a question best answered by the tor-talk@ community, I think. Do you want to announce your service there? Maybe you want to add a link to the Onionoo protocol page (https://onionoo.torproject.org/) to give people an idea what other information could be added to your service?
And do you mind if we include a short description and link to your service in the second issue of Tor Weekly News?
https://lists.torproject.org/pipermail/tor-talk/2013-July/028770.html
I think it's really important to get you some users now who're willing to give you feedback.
Thanks, Karsten
On Fri, Jul 05, 2013 at 09:18:45AM +0200, Karsten Loesing wrote:
On 7/3/13 5:16 PM, me@rndm.de wrote:
Okay. Looking forward to seeing your tool display Onionoo's bridge details!
I updated it to display bridge detail and enable bridge search. Works fine so far. You can now toggle between relays or bridges in the search results.
This is awesome! Repeating the link here, so that others can follow:
Sleek. ;-)
I thought I saw on this thread that searching for bridges by their fingerprints is supposed to work, but it does not appear to for mine.
I'm just pasting the hex string (like "6E2FF9C59A809882E1BAF2BD19508B1079B5C0E4", but that's not my real one) from the data/fingerprint file on my bridge into the search bar, and it says "No bridge found :(".
Did I misunderstand?
Thanks,
- Ian
Am 2013-07-05 07:38, schrieb Ian Goldberg:
On Fri, Jul 05, 2013 at 09:18:45AM +0200, Karsten Loesing wrote:
On 7/3/13 5:16 PM, me@rndm.de wrote:
Okay. Looking forward to seeing your tool display Onionoo's bridge details!
I updated it to display bridge detail and enable bridge search. Works fine so far. You can now toggle between relays or bridges in the search results.
This is awesome! Repeating the link here, so that others can follow:
Sleek. ;-)
I thought I saw on this thread that searching for bridges by their fingerprints is supposed to work, but it does not appear to for mine.
I'm just pasting the hex string (like "6E2FF9C59A809882E1BAF2BD19508B1079B5C0E4", but that's not my real one) from the data/fingerprint file on my bridge into the search bar, and it says "No bridge found :(".
Did I misunderstand?
Thanks,
- Ian
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Mh do you used your unhashed bridge fingerprint or a hashed one? Afaik it's impossible to search for bridges using the unhashed fingerprint.
You could directly query the api with https://onionoo.torproject.org/summary?search=YOURFINGERPRINTHERE and see if there is an item in the bridges array.
On Fri, Jul 05, 2013 at 10:57:28AM -0400, me@rndm.de wrote:
Sleek. ;-)
I thought I saw on this thread that searching for bridges by their fingerprints is supposed to work, but it does not appear to for mine.
I'm just pasting the hex string (like "6E2FF9C59A809882E1BAF2BD19508B1079B5C0E4", but that's not my real one) from the data/fingerprint file on my bridge into the search bar, and it says "No bridge found :(".
Did I misunderstand?
Thanks,
- Ian
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Mh do you used your unhashed bridge fingerprint or a hashed one? Afaik it's impossible to search for bridges using the unhashed fingerprint.
You could directly query the api with https://onionoo.torproject.org/summary?search=YOURFINGERPRINTHERE and see if there is an item in the bridges array.
I used the one in the data/fingerprint file. I thought the suggestion earlier in this thread was that the javascript would hash it for me. I guess not?
- Ian
Am 2013-07-05 11:00, schrieb Ian Goldberg:
On Fri, Jul 05, 2013 at 10:57:28AM -0400, me@rndm.de wrote:
Sleek. ;-)
I thought I saw on this thread that searching for bridges by their fingerprints is supposed to work, but it does not appear to for mine.
I'm just pasting the hex string (like "6E2FF9C59A809882E1BAF2BD19508B1079B5C0E4", but that's not my real one) from the data/fingerprint file on my bridge into the search bar, and it says "No bridge found :(".
Did I misunderstand?
Thanks,
- Ian
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Mh do you used your unhashed bridge fingerprint or a hashed one? Afaik it's impossible to search for bridges using the unhashed fingerprint.
You could directly query the api with https://onionoo.torproject.org/summary?search=YOURFINGERPRINTHERE and see if there is an item in the bridges array.
I used the one in the data/fingerprint file. I thought the suggestion earlier in this thread was that the javascript would hash it for me. I guess not?
- Ian
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Mh I guess I need to refactor the search input to make it a bit more clear. Using ?search searches for fingerprints, nicknames or beginning of ip addresses in relays and nicknames or hashed fingerprints in bridges.
Atm I only hash all the requests for bridge or relay details.
On 7/5/13 7:28 PM, me@rndm.de wrote:
Mh I guess I need to refactor the search input to make it a bit more clear. Using ?search searches for fingerprints, nicknames or beginning of ip addresses in relays and nicknames or hashed fingerprints in bridges.
Atm I only hash all the requests for bridge or relay details.
Let me try to explain the idea behind the fingerprint hash madness:
We want to avoid that original bridge fingerprints go on the wire or reach the Onionoo server. Even though we use https, and even though the Onionoo server is, in theory, trusted.
However, it would be extremely hard to make sure that bridge operators never paste the content of there data/fingerprint file into their browser. It's the natural thing to do.
The solution is that the browser applies SHA1 on *any* 40 hex character long fingerprint it receives from the user. Onionoo can then look up the hashed bridge fingerprint in its list.
To be more precise, Onionoo looks up 40 hex character long fingerprints in four lists:
- original relay fingerprints: that's how Atlas and your new tool support searches for relays by fingerprint *right now*.
- hashed bridge fingerprints: that's what your tool would request when users paste the content of their data/fingerprint file and your tool hashes it.
- hashed relay fingerprints: if your tool hashes all fingerprints, including relay fingerprints, Onionoo wouldn't find relays anymore, unless it also looks them up by hashed relay fingerprint.
- hashed hashed bridge fingerprints: if people see their hashed bridge fingerprint on a details page and paste it into the search field, your tool would hash it once more, so Onionoo needs some way to find the bridge again.
Note that you don't need to hash anything you receive in a response from Onionoo. So, requests for bridge or relay details can use the same identifiers that you receive in summary files. These are all safe.
Also note that this doesn't work for hex strings with 39 or fewer characters. Nothing we can do about that, so leave them unchanged.
tl;dr: Your tool should apply SHA1 on all 40 hex character search inputs.
Best, Karsten
Nothing wrong from a legal perspective (IANAL), but Tor Onionoo Search isn't as catchy as it could be. Hmm, how about picking one of Atlas' children's names (http://en.wikipedia.org/wiki/Atlas_%28mythology%29) for your project? Greek mythology is full of fun project names.
Mh I started to look into some names but haven't found a fitting one. If anyone got any suggestion i would appreciate it.
How about "Globe" or "Globus"?
I don't know if it's too general, maybe combining it with something like "Onion Globe"?
That's a question best answered by the tor-talk@ community, I think. Do you want to announce your service there? Maybe you want to add a link to the Onionoo protocol page (https://onionoo.torproject.org/) to give people an idea what other information could be added to your service?
And do you mind if we include a short description and link to your service in the second issue of Tor Weekly News?
https://lists.torproject.org/pipermail/tor-talk/2013-July/028770.html
I think it's really important to get you some users now who're willing to give you feedback.
Yeah that would be great. Feedback is always appreciated.
What would be the best place to ask questions like supported browsers, missing features etc.?
On 7/5/13 4:52 PM, me@rndm.de wrote:
Nothing wrong from a legal perspective (IANAL), but Tor Onionoo Search isn't as catchy as it could be. Hmm, how about picking one of Atlas' children's names (http://en.wikipedia.org/wiki/Atlas_%28mythology%29) for your project? Greek mythology is full of fun project names.
Mh I started to look into some names but haven't found a fitting one. If anyone got any suggestion i would appreciate it.
How about "Globe" or "Globus"?
I don't know if it's too general, maybe combining it with something like "Onion Globe"?
Sure, why not?
That's a question best answered by the tor-talk@ community, I think. Do you want to announce your service there? Maybe you want to add a link to the Onionoo protocol page (https://onionoo.torproject.org/) to give people an idea what other information could be added to your service?
And do you mind if we include a short description and link to your service in the second issue of Tor Weekly News?
https://lists.torproject.org/pipermail/tor-talk/2013-July/028770.html
I think it's really important to get you some users now who're willing to give you feedback.
Yeah that would be great. Feedback is always appreciated.
What would be the best place to ask questions like supported browsers, missing features etc.?
That would be tor-talk@.
Thanks, Karsten
Karsten Loesing:
On 7/3/13 5:16 PM, me@rndm.de wrote:
I updated it to display bridge detail and enable bridge search. Works fine so far. You can now toggle between relays or bridges in the search results.
This is awesome! Repeating the link here, so that others can follow:
Small issues I spoted while playing with it:
* If a search, then select 'Bridges' view, visit a bridge page, and then use the back button of my browser it switches back to the 'Relays' view. Not ideal.
* IMHO, the y-axis of the bandwidth graphs should always start at 0 so multiple relays can be compared by layout graphs side by side.
How close is this piece of code to have feature parity with Atlas?
On 7/6/13 9:01 AM, Lunar wrote:
Karsten Loesing:
On 7/3/13 5:16 PM, me@rndm.de wrote:
I updated it to display bridge detail and enable bridge search. Works fine so far. You can now toggle between relays or bridges in the search results.
This is awesome! Repeating the link here, so that others can follow:
Small issues I spoted while playing with it:
If a search, then select 'Bridges' view, visit a bridge page, and then use the back button of my browser it switches back to the 'Relays' view. Not ideal.
IMHO, the y-axis of the bandwidth graphs should always start at 0 so multiple relays can be compared by layout graphs side by side.
Can you add these to GitHub's issue tracker?
https://github.com/makepanic/emberjs-tor-onionoo/issues
How close is this piece of code to have feature parity with Atlas?
I think there are no features in Atlas that this new tool doesn't have. To the contrary, this tool has features that we wanted to have in Atlas for a long time (list 10 fastest relays on start page, show bridge details).
However, I don't have plans to retire Atlas just yet. I think it's fine to have more than one website providing access to Onionoo data. Yay, diversity.
Best, Karsten
06.07.2013 12:05, Karsten Loesing:
On 7/6/13 9:01 AM, Lunar wrote:
Karsten Loesing:
On 7/3/13 5:16 PM, me@rndm.de wrote:
I updated it to display bridge detail and enable bridge search. Works fine so far. You can now toggle between relays or bridges in the search results.
This is awesome! Repeating the link here, so that others can follow:
Small issues I spoted while playing with it:
If a search, then select 'Bridges' view, visit a bridge page, and then use the back button of my browser it switches back to the 'Relays' view. Not ideal.
IMHO, the y-axis of the bandwidth graphs should always start at 0 so multiple relays can be compared by layout graphs side by side.
Can you add these to GitHub's issue tracker?
@Lunar If you don't have access to Github, I'll can add them as well.
How close is this piece of code to have feature parity with Atlas?
I think there are no features in Atlas that this new tool doesn't have. To the contrary, this tool has features that we wanted to have in Atlas for a long time (list 10 fastest relays on start page, show bridge details).
@makepanic Could you please add this features to Atlas?
However, I don't have plans to retire Atlas just yet. I think it's fine to have more than one website providing access to Onionoo data. Yay, diversity.
@Karsten Hooray, diversity. Yes, please don't retire Atlas.
Best, bastik
Am 2013-07-06 06:33, schrieb Sebastian G. <bastik.tor>:
06.07.2013 12:05, Karsten Loesing:
On 7/6/13 9:01 AM, Lunar wrote:
Karsten Loesing:
On 7/3/13 5:16 PM, me@rndm.de wrote:
I updated it to display bridge detail and enable bridge search. Works fine so far. You can now toggle between relays or bridges in the search results.
This is awesome! Repeating the link here, so that others can follow:
Small issues I spoted while playing with it:
If a search, then select 'Bridges' view, visit a bridge page, and then use the back button of my browser it switches back to the 'Relays' view. Not ideal.
IMHO, the y-axis of the bandwidth graphs should always start at 0 so multiple relays can be compared by layout graphs side by side.
Can you add these to GitHub's issue tracker?
@Lunar If you don't have access to Github, I'll can add them as well.
Added them both and fixed the bug where it defaults the search to 'relays'. The last version should also hash all the 40char hex strings for search requests.
How close is this piece of code to have feature parity with Atlas?
I think there are no features in Atlas that this new tool doesn't have. To the contrary, this tool has features that we wanted to have in Atlas for a long time (list 10 fastest relays on start page, show bridge details).
@makepanic Could you please add this features to Atlas?
Ok. Is there anything i need to contribute to the project?
However, I don't have plans to retire Atlas just yet. I think it's fine to have more than one website providing access to Onionoo data. Yay, diversity.
@Karsten Hooray, diversity. Yes, please don't retire Atlas.
Best, bastik
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
06.07.2013 13:36, me@rndm.de:
Am 2013-07-06 06:33, schrieb Sebastian G. <bastik.tor>: [...]
How close is this piece of code to have feature parity with Atlas?
I think there are no features in Atlas that this new tool doesn't have. To the contrary, this tool has features that we wanted to have in Atlas for a long time (list 10 fastest relays on start page, show bridge details).
@makepanic Could you please add this features to Atlas?
Ok. Is there anything i need to contribute to the project?
The ability to understand and write JavaScript code. [1]
[1] https://lists.torproject.org/pipermail/tor-talk/2013-April/028018.html
Best, bastik
On 7/6/13 1:36 PM, me@rndm.de wrote:
Am 2013-07-06 06:33, schrieb Sebastian G. <bastik.tor>:
06.07.2013 12:05, Karsten Loesing:
On 7/6/13 9:01 AM, Lunar wrote:
Karsten Loesing:
On 7/3/13 5:16 PM, me@rndm.de wrote:
I updated it to display bridge detail and enable bridge search. Works fine so far. You can now toggle between relays or bridges in the search results.
This is awesome! Repeating the link here, so that others can follow:
Small issues I spoted while playing with it:
If a search, then select 'Bridges' view, visit a bridge page, and then use the back button of my browser it switches back to the 'Relays' view. Not ideal.
IMHO, the y-axis of the bandwidth graphs should always start at 0 so multiple relays can be compared by layout graphs side by side.
Can you add these to GitHub's issue tracker?
@Lunar If you don't have access to Github, I'll can add them as well.
Added them both and fixed the bug where it defaults the search to 'relays'. The last version should also hash all the 40char hex strings for search requests.
Neat!
How close is this piece of code to have feature parity with Atlas?
I think there are no features in Atlas that this new tool doesn't have. To the contrary, this tool has features that we wanted to have in Atlas for a long time (list 10 fastest relays on start page, show bridge details).
@makepanic Could you please add this features to Atlas?
Ok. Is there anything i need to contribute to the project?
Clone the repo, make changes, push your branch somewhere, and create a Trac ticket or comment on an existing ticket that you want someone to review your changes. Arturo or I will then review your branch, merge them, and deploy them on atlas.torproject.org.
Best, Karsten
However, I don't have plans to retire Atlas just yet. I think it's fine to have more than one website providing access to Onionoo data. Yay, diversity.
@Karsten Hooray, diversity. Yes, please don't retire Atlas.
Best, bastik
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
On Sat, Jul 06, 2013 at 07:36:01AM -0400, me@rndm.de wrote:
Added them both and fixed the bug where it defaults the search to 'relays'. The last version should also hash all the 40char hex strings for search requests.
Hmm. I do see that it's hashing the data/fingerprint entry, but onionoo is returning "no entry".
Ah, my bridge is configured as
BridgeRelay 1 PublishServerDescriptor 0
Does the latter mean that stats are also not pushed to onionoo? It's set that way for one of the funders, but it would be great if I could somehow see how much usage it's getting.
Thanks,
- Ian
On 7/6/13 3:36 PM, Ian Goldberg wrote:
On Sat, Jul 06, 2013 at 07:36:01AM -0400, me@rndm.de wrote:
Added them both and fixed the bug where it defaults the search to 'relays'. The last version should also hash all the 40char hex strings for search requests.
Hmm. I do see that it's hashing the data/fingerprint entry, but onionoo is returning "no entry".
Ah, my bridge is configured as
BridgeRelay 1 PublishServerDescriptor 0Does the latter mean that stats are also not pushed to onionoo? It's set that way for one of the funders, but it would be great if I could somehow see how much usage it's getting.
Yes, that setting makes your bridge not publish anything to Tonga, not even extra-info descriptors containing bandwidth or usage statistics.
Hmm. I wonder if we need a setting for bridges to publish descriptors but for BridgeDB to not give them out. Would that satisfy funder requirements, too?
Best, Karsten
On Sat, Jul 06, 2013 at 09:36:32AM -0400, Ian Goldberg wrote:
Ah, my bridge is configured as
BridgeRelay 1 PublishServerDescriptor 0Does the latter mean that stats are also not pushed to onionoo? It's set that way for one of the funders, but it would be great if I could somehow see how much usage it's getting.
You might like https://trac.torproject.org/projects/tor/ticket/6852
(Well, not its current status or progress, but the idea behind it.)
--Roger
On 7/5/13 9:18 AM, Karsten Loesing wrote:
On 7/3/13 5:16 PM, me@rndm.de wrote:
btw. is there data (bandwidth or something else) that is really important for a Atlas user when viewing a detail page or is everything equally important?
That's a question best answered by the tor-talk@ community, I think.
Actually, I should give this question a try myself. Here's a list of fields in relay details documents and whether I consider them important for a relay details page or not:
nickname (++) fingerprint (++) or_addresses (++) exit_addresses (++) dir_address (++) last_seen (+) last_changed_address_or_port (--) first_seen (+) running (++) flags (++) country (++) country_name (++) region_name (+) city_name (+) latitude (+) longitude (+) as_number (+) as_name (+) consensus_weight (+) host_name (+) last_restarted (+) bandwidth_rate (+) bandwidth_burst (+) observed_bandwidth (+) advertised_bandwidth (-) exit_policy (++) exit_policy_summary (+) contact (++) platform (++) family (++) advertised_bandwidth_fraction (-) consensus_weight_fraction (-) guard_probability (-) middle_probability (-) exit_probability (-)
And here's the same for a bridge details page:
nickname (++) hashed_fingerprint (++) or_addresses (--) last_seen (+) first_seen (+) running (++) flags (-) last_restarted (+) advertised_bandwidth (-) platform (++) pool_assignment (++)
Hope that helps.
Best, Karsten
-
Ian Goldberg -
Karsten Loesing -
Lunar -
me＠rndm.de -
Moritz Bartl -
Roger Dingledine -
Sebastian G. <bastik.tor>