The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2024-03-27T21:17:43Zhttps://gitlab.torproject.org/tpo/web/community/-/issues/339Update links at the Vanity Addresses page2024-03-27T21:17:43ZSilvio RhattoUpdate links at the Vanity Addresses page# Description
[Vanity Addresses page](https://community.torproject.org/onion-services/advanced/vanity-addresses/) needs updated links/references.
Specifically, these references are outdated:
* [eotk/docs.d/TIPS-FOR-MINING-ONIONS.md at...# Description
[Vanity Addresses page](https://community.torproject.org/onion-services/advanced/vanity-addresses/) needs updated links/references.
Specifically, these references are outdated:
* [eotk/docs.d/TIPS-FOR-MINING-ONIONS.md at master · alecmuffett/eotk](https://github.com/alecmuffett/eotk/blob/master/docs.d/TIPS-FOR-MINING-ONIONS.md)
* [Onion Services UX Proposals · Wiki · The Tor Project / Onion Services / Onion Support · GitLab](https://gitlab.torproject.org/tpo/onion-services/onion-support/-/wikis/Documentation/Onion-Services-UX-Proposals)
And can be replaced by:
* [Mining Onion Service keys - Onionspray](https://tpo.pages.torproject.net/onion-services/onionspray/guides/mining/)
* [Usability intro - The Onion Plan](https://tpo.pages.torproject.net/onion-services/onionplan/proposals/usability/)
A reference to [Onionmine](https://gitlab.torproject.org/tpo/onion-services/onionmine/) would also be informative.
# Tasks
* [ ] Replace the oudated references with the newer ones.
* [ ] Add a reference to Onionmine.
# Time estimation
* Complexity: negligible (0.1 day)
* Uncertainty: low (x1.1)
* [Reference](https://jacobian.org/2021/may/25/my-estimation-technique/) (adapted)Silvio RhattoSilvio Rhatto2024-07-31https://gitlab.torproject.org/tpo/web/support/-/issues/357Add HashRing to the glossary2024-02-13T20:36:21ZemmapeelAdd HashRing to the glossaryWe need to add HashRing to the glossary, there are some contents that mention it on passing and most of the readers and translators think it is a typo of hashing, but it is not:
```
14:19 < nina13[m]> hi! There is a glossary term to tr...We need to add HashRing to the glossary, there are some contents that mention it on passing and most of the readers and translators think it is a typo of hashing, but it is not:
```
14:19 < nina13[m]> hi! There is a glossary term to translate "hashring" (https://hosted.weblate.org/translate/tor/glossary/ru/?checksum=3b2b6b707f90ff59)
currently it is translated in Russian and other eastern european languages as "hashing". So I wonder is it just "hashing" or hashRing like in Rust (https://docs.rs/hashring/latest/hashring/)
14:32 < = trinity-1686a> "hashing" wouldn't be a good translation. Scouting the internet, I found two instances of "Хэшринг" which seems more
accurate, I couldn't find any other translation that seemed correct (but I don't speak a word of russian)
14:38 < trinity-1686a> it's related to the concept of "consistent hashing". There is a picture on
https://en.wikipedia.org/wiki/Consistent_hashing#Basic_technique which explain why the name hash+ring (you hash something, treat the
result as a position on a ring. To know where to store your thing, you walk on the ring until you find a server)
```Jérôme Charaouilavamind@torproject.orgJérôme Charaouilavamind@torproject.orghttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/41064Update tools/signing/README and add a tools/signing/machines-setup/README2024-01-18T15:05:06ZboklmUpdate tools/signing/README and add a tools/signing/machines-setup/READMEWe should update `tools/signing/README` for latest changes, and also
point to the issue templates for usage information.
We should also create `tools/signing/machines-setup/README` to document
how the setup of the signing machines is done.We should update `tools/signing/README` for latest changes, and also
point to the issue templates for usage information.
We should also create `tools/signing/machines-setup/README` to document
how the setup of the signing machines is done.boklmboklmhttps://gitlab.torproject.org/tpo/core/arti-doc-project-2023/-/issues/83Deploying Arti Documentation2024-03-05T15:10:55ZpkafeiDeploying Arti DocumentationOur team is almost finished with the Arti documentation, and we are now in the process of deploying the site. We suggest deploying Arti in the current repo that it's located in using [Gitlab Pages](https://docs.gitlab.com/ee/user/project...Our team is almost finished with the Arti documentation, and we are now in the process of deploying the site. We suggest deploying Arti in the current repo that it's located in using [Gitlab Pages](https://docs.gitlab.com/ee/user/project/pages/).
We think this is the most convenient approach, but there are several issues we want to clear up before we proceed:
1. Is the [current documentation site](https://tpo.pages.torproject.net/core/arti/) repo located [here](https://gitlab.torproject.org/tpo/core/arti-doc-project-2023/-/tree/main/doc)? If so, is there a compelling reason for us to point the new docs to this new location and deploy them from the docs directory?
2. How do we handle the domain name? Will the new documentation have a new domain name?
Thanks, and let us know if we're missing anything! cc @gaba @oluchinwenyi @charlie-doc-writerAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/tpo/core/arti/-/issues/1249Arti documentation next phase2024-01-18T18:02:26ZGabagaba@torproject.orgArti documentation next phaseDocumentWrite is almost done with the Arti documentation. We need to make a decision on
- how deployment will happen for arti.torproject.org. Are we move the documentation from DocumentWrite into this arti repository and deploy it to a...DocumentWrite is almost done with the Arti documentation. We need to make a decision on
- how deployment will happen for arti.torproject.org. Are we move the documentation from DocumentWrite into this arti repository and deploy it to arti.torproject.org through gitlab pages?
- deprecation of old documentation. Is there any check we can do to be sure that everything from the old documentation is in the new one?
On parallel we need "training" from DocumentWrite to understand their work and be sure that we can keep maintaining this documentation in the easiest way possible.
Thoughts?https://gitlab.torproject.org/tpo/core/arti/-/issues/1235Merge/move `hssvc-ipt-algorithm.md` documents into codebase2024-01-15T18:07:18ZNick MathewsonMerge/move `hssvc-ipt-algorithm.md` documents into codebaseThis documentation should be internal to our codebase somewhere: Maybe in `ipt_mgr` or `ipt_establish`.
We should not move this carelessly: we should review it, and make sure it's still relevant.This documentation should be internal to our codebase somewhere: Maybe in `ipt_mgr` or `ipt_establish`.
We should not move this carelessly: we should review it, and make sure it's still relevant.https://gitlab.torproject.org/tpo/core/arti/-/issues/1222Add central documentation for our filesystem layout2024-02-01T15:43:34ZNick MathewsonAdd central documentation for our filesystem layoutSomewhere in doc/dev, we should document all the files that we create or look at.
This will include:
* `tor-keymgr` stuff, possibly by reference
* All state files
* All onion-service-related files
* All cache files
* All locks...Somewhere in doc/dev, we should document all the files that we create or look at.
This will include:
* `tor-keymgr` stuff, possibly by reference
* All state files
* All onion-service-related files
* All cache files
* All locks
* All configuration files
This should replace `crates/tor-hsservice/src/state_dir.md` (cc @diziet)https://gitlab.torproject.org/tpo/web/community/-/issues/337Replace EOTK repository URL with Onionspray's2024-03-21T21:39:43ZSilvio RhattoReplace EOTK repository URL with Onionspray's# Tasks
* [x] Update EOTK link at https://community.torproject.org/onion-services/, pointing to https://gitlab.torproject.org/tpo/onion-services/eotk.
* [x] Update the repository link in other relevant pages.
* [x] Replace, again, this ...# Tasks
* [x] Update EOTK link at https://community.torproject.org/onion-services/, pointing to https://gitlab.torproject.org/tpo/onion-services/eotk.
* [x] Update the repository link in other relevant pages.
* [x] Replace, again, this time with [Onionspray](https://gitlab.torproject.org/tpo/onion-services/onionspray).
# Time estimation
* Complexity: very small (0.5 day)
* Uncertainty: low (x1.1)
* [Reference](https://jacobian.org/2021/may/25/my-estimation-technique/) (adapted)
/cc @gusSilvio RhattoSilvio Rhatto2024-03-28https://gitlab.torproject.org/tpo/tpa/team/-/issues/41456monitor technical debt and legacy2024-03-27T15:29:42Zanarcatmonitor technical debt and legacyI often say that we have a huge technical debt in TPA, and that we keep needing to close things down and document and so on.
But we do not have hard data on this. After reading [Managing Technical Debt](https://jacobian.org/2023/dec/20/...I often say that we have a huge technical debt in TPA, and that we keep needing to close things down and document and so on.
But we do not have hard data on this. After reading [Managing Technical Debt](https://jacobian.org/2023/dec/20/tech-debt/), I realized we should at least keep track of metrics about this. What's interesting about that article is it says we shouldn't necessarily set *targets*, but keeping track of metrics would be a good start.
He specifically [suggests DORA metrics](https://jacobian.org/2022/jun/17/dora-metrics/), but I'm not sure it's the best match for us. Here's what I think we should monitor:
* tickets
* "lead time" (time between when a ticket enters backlog/next/doing and closing)
* start using the ~"Technical Debt" ticket and measure ticket counts
* general per-queue ticket counts (already done in monthly reports, put in prometheus, see https://gitlab.torproject.org/tpo/tpa/team/-/issues/40591)
* incidents:
* "lead time" is specially important here: how long do tickets get opened in incidents? might also be a measure of MTTR (mean time to recovery)
* "change failure rate": measure how many incidents are caused by deployment failures
* documentation: systematically measure how many services we have and how well they are documented (this is partially done, by hand, in the `service.md` wiki page, but could be somehow automated)
* untracked package counts: use anarcat's [puppet-package-check](https://gitlab.com/anarcat/scripts/-/blob/main/puppet-package-check?ref_type=heads) to generate metrics on how many packages are *not* managed by puppet, per host, as a rough estimate of the "puppetization ratio"
* unit test coverage: across all our software projects (or maybe per project?), what is the coverage of unit tests? (requires CI and extraction of those numbers in an exporter)
* out of date systems: how long does it take to update the fleet, and how long do we live on LTS? (at least partly tracked in Prometheus now, but not retained long enough to have good metrics, see also #40330)
The end result here is a small set of metrics that describe the current state of affairs, and its evolution over time. It will allow us to more easily realize when we're in trouble (e.g. https://gitlab.torproject.org/tpo/tpa/team/-/issues/41411) and evaluate how much effort we should put into this.
It might be more effective to have those metrics beyond the "one year" mark. Ticket counts, for example, are kept forever in the minutes, and that's a good thing, so we should consider expanding the storage retention here (#40330).
One thing Kaplan-Moss advises is to set time apart to deal with technical debt, he advises 10%. He also says we shouldn't set "sprints" to deal with technical debt, but I disagree with that: I have found that Debian upgrades are working well with sprints and wonder to what else we could extend the practice. On the other hand, the docs hack week wasn't a clear success for us, so maybe he's at least partly right in some aspects.cleanup and publish the sysadmin codebaseanarcatanarcathttps://gitlab.torproject.org/tpo/ux/design/-/issues/67Design page templates for design-dot2024-01-29T19:09:25ZdonutsDesign page templates for design-dotWorking file here: [Figma / Marble / Design-dot](https://www.figma.com/file/nIpahk0b9VMaeEnubiO33g/Marble?type=design&node-id=291%3A6468&mode=design&t=5VNXs9nes3se88ax-1)Working file here: [Figma / Marble / Design-dot](https://www.figma.com/file/nIpahk0b9VMaeEnubiO33g/Marble?type=design&node-id=291%3A6468&mode=design&t=5VNXs9nes3se88ax-1)design-dot MVPdonutsdonutshttps://gitlab.torproject.org/tpo/ux/team/-/issues/93Project idea: Design and build a replacement for styleguide-dot2023-12-13T05:10:58ZdonutsProject idea: Design and build a replacement for styleguide-dotAt the Tor Project hackweek in November 2023, the UX Team explored a replacement for our existing style guide ([styleguide.torproject.org](https://styleguide.torproject.org/)), with the stated goal:
> The UX Team have been discussing re...At the Tor Project hackweek in November 2023, the UX Team explored a replacement for our existing style guide ([styleguide.torproject.org](https://styleguide.torproject.org/)), with the stated goal:
> The UX Team have been discussing replacing the [existing styleguide](http://styleguide.torproject.org) with a new resource that's wider in scope – e.g. "design.torproject.org". In addition to updating our brand and web guidelines given their evolution over the past few years, we're also considering adding new sections to document our human-centered design principals, user research program, and overall methodology. The revised portal should serve as a central point of reference for external resources too, including for example our Figma libraries for the browser, web and VPN, and any open source design resources we use.
During the hackweek, we made good progress planning the structure of the future site and designed some initial templates. However it also became clear that the scope we were aiming for was simply too large, and that it would be better to focus on deploying a basic MVP that covers the same subjects as the current style guide—those being:
- Home page
- Styles
- Color: featuring the new 10 point color system, core brand colors, and semantic uses.
- Typography: including updates to our brand fonts at display and body sizes.
- Assets
- Brand: featuring the new logo, if approved (see https://gitlab.torproject.org/tpo/ux/team/-/issues/92), the new Tor Browser application icons, and guidelines for use.
- Iconography: including custom icons for Tor Browser and our new brand icons (see https://gitlab.torproject.org/tpo/ux/design/-/issues/62).
- Illustration: featuring the new illustrations being developed by Nico (see https://gitlab.torproject.org/tpo/ux/design/-/issues/61).https://gitlab.torproject.org/tpo/ux/team/-/issues/91Project idea: Dedicated release notes and lo-fi public roadmaps2023-12-09T03:31:11ZdonutsProject idea: Dedicated release notes and lo-fi public roadmapsAt present, release notes for our software are posted either to the blog, the forum or both. We could improve on this with a dedicated feed for release notes separate from the blog, that uses a custom layout to improve the formatting for...At present, release notes for our software are posted either to the blog, the forum or both. We could improve on this with a dedicated feed for release notes separate from the blog, that uses a custom layout to improve the formatting for release posts.
Some inspiration can be drawn from:
- [Firefox](https://www.mozilla.org/en-US/firefox/releases/): Specifically the way they split up the release notes into different sections, like "New", "Fixed" etc.
- [DuckDuckGo](https://duckduckgo.com/updates): While these aren't release notes, it's a nice example of how updates ti multiple pieces of software can be combined to create a sense of momentum across the org.
- [Linear](https://linear.app/changelog): These are just really nicely designed.
Major releases that include more of a narrative could still justify an accompanying blog post, however.
I think it would also be great to provide a general sense for what's coming in the near future too in a sort of lo-fi public roadmap, that doesn't promise specific windows for delivery.https://gitlab.torproject.org/tpo/ux/team/-/issues/90Project idea: Feature comparison page2023-12-08T19:07:35ZdonutsProject idea: Feature comparison pageAfter the VPN is released, a feature comparison page for torproject.org/download would help users to choose the right app. It could also be expanded to include other apps. Some of the points of comparison it covers could be:
- App type
...After the VPN is released, a feature comparison page for torproject.org/download would help users to choose the right app. It could also be expanded to include other apps. Some of the points of comparison it covers could be:
- App type
- Platform
- Connection type
- Fingerprinting protections
- License
- Developer
- Distributor
I imagine at minimum it should feature Tor Browser, Mullvad Browser and the Tor VPN—but it could also be expanded to include trusted Tor-powered apps created by our community partners on a second tab, e.g. Tail, Orbot, Onion Browser, Onionshare and others.https://gitlab.torproject.org/tpo/ux/team/-/issues/88Project idea: Create an "insights" dashboard for user research2023-12-08T18:46:19ZdonutsProject idea: Create an "insights" dashboard for user researchAt present, the results of our user research are scattered across several different blog posts and reports (themselves often a mix of public and private, and frequently published on completely different platforms). In addition to providi...At present, the results of our user research are scattered across several different blog posts and reports (themselves often a mix of public and private, and frequently published on completely different platforms). In addition to providing a single home for our user research reports, it would be great to create a simple dashboard summarizing findings that we still consider current, including:
- Snapshot of important metrics (linking to metrics.torproject.org)
- Recent qualitative findings
- Locations and participant numbers
- Top pain points
- Questions participants frequently ask
- A link to submit a question to the UX team, that isn't answered in our current data
The new style guide would be one potential home for this page.https://gitlab.torproject.org/tpo/ux/team/-/issues/86Project idea: Document interface guidelines for Tor-powered apps2023-12-14T17:36:39ZdonutsProject idea: Document interface guidelines for Tor-powered appsAfter the new style guide is in place, we would like to add a section documenting some of the common interfaces Tor-powered apps often need to implement, for example:
- Bootstrapping
- Circuits
- Onion services
- Censorship circumventio...After the new style guide is in place, we would like to add a section documenting some of the common interfaces Tor-powered apps often need to implement, for example:
- Bootstrapping
- Circuits
- Onion services
- Censorship circumvention
The idea would be to provide application agnostic wireframes of each common interface, accompanied with short descriptions and links to other materials for implementation. The goal here is to promote greater UX consistency in the Tor ecosystem, and nudge developers towards solutions that have been validated by user research.
However we don't want to be overly prescriptive and demand that developers from our community implement Tor Browser's current UX. Instead, in addition to ideas that we've came up with internally, we should also look to the creative solutions our peers in the community have developed when creating our application agnostic UX. Similarly, after the guidelines have been established, developers shouldn't be bound to follow them exactly—and instead be encouraged to modify the UX when necessary to suit their apps' individual use-cases.
At present, I imagine the focus here to be on Tor-powered functionality specifically. While we could expand the scope to include UX recommendations for more general privacy and security features, we should take into consideration our capacity to maintain this resource in the longer term.https://gitlab.torproject.org/tpo/anti-censorship/gettor-project/OnionSproutsBot/-/issues/58Improve and correct the text answering "What is Tor?"2023-12-14T08:50:00Zebanamebanam@torproject.orgImprove and correct the text answering "What is Tor?"We should improve the text answering "What is Tor?"
This is what we have right now:
![ima_2bcbb33.jpeg](/uploads/4edbba53c49ae6a336a19626b1bd1ddc/ima_2bcbb33.jpeg){width=242 height=267}
relevant file: https://gitlab.torproject.org/tpo...We should improve the text answering "What is Tor?"
This is what we have right now:
![ima_2bcbb33.jpeg](/uploads/4edbba53c49ae6a336a19626b1bd1ddc/ima_2bcbb33.jpeg){width=242 height=267}
relevant file: https://gitlab.torproject.org/tpo/anti-censorship/gettor-project/OnionSproutsBot/-/blob/main/OnionSproutsBot/plugins/dialogue.py#L102https://gitlab.torproject.org/tpo/web/onion-mkdocs/-/issues/9Support building from a shared folder2023-12-05T13:27:18ZSilvio RhattoSupport building from a shared folderSupport for building from a public folder such as a [Nextcloud][] share populated with Markdown and other files such as a `mkdocs.yml` config.
Originally suggested during the [2023 Hackweek evaluation](https://tpo.pages.torproject.net/c...Support for building from a public folder such as a [Nextcloud][] share populated with Markdown and other files such as a `mkdocs.yml` config.
Originally suggested during the [2023 Hackweek evaluation](https://tpo.pages.torproject.net/community/hackweek/past/2023/#questions).
[Nextcloud]: https://nextcloud.comhttps://gitlab.torproject.org/tpo/network-health/metrics/website/-/issues/40106Details API returning undocumented `contact` for bridges2023-11-29T20:48:03ZSarthik Guptasarthikg@icloud.comDetails API returning undocumented `contact` for bridgesContrary to the key-value pairs listed at https://metrics.torproject.org/onionoo.html#details_bridge,
Details API Response contains `contact` key for bridges as can be tested in the response for the following api, https://onionoo.torpro...Contrary to the key-value pairs listed at https://metrics.torproject.org/onionoo.html#details_bridge,
Details API Response contains `contact` key for bridges as can be tested in the response for the following api, https://onionoo.torproject.org/details?limit=4&search=scriptonhttps://gitlab.torproject.org/tpo/network-health/metrics/onionoo/-/issues/40041Details API returning undocumented `contact` for bridges2023-11-27T14:49:33ZSarthik Guptasarthikg@icloud.comDetails API returning undocumented `contact` for bridgesContrary to the key-value pairs listed at https://metrics.torproject.org/onionoo.html#details_bridge,
Details API Response contains `contact` key for bridges as can be tested in the response for the following api, https://onionoo.torpro...Contrary to the key-value pairs listed at https://metrics.torproject.org/onionoo.html#details_bridge,
Details API Response contains `contact` key for bridges as can be tested in the response for the following api, https://onionoo.torproject.org/details?limit=4&search=scriptonhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/41024Fix android filenames in Release Prep issue templates2023-11-22T17:53:09ZboklmFix android filenames in Release Prep issue templatesIn the issue templates, the section about Google Plays says to upload
the `*.multi.apk` APKs. However since we renamed the filenames, it
should now be `tor-browser-android-*.apk`.In the issue templates, the section about Google Plays says to upload
the `*.multi.apk` APKs. However since we renamed the filenames, it
should now be `tor-browser-android-*.apk`.boklmboklm