The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2024-03-13T14:33:03Zhttps://gitlab.torproject.org/tpo/community/policies/-/issues/16Write a proposal for acceptable/unacceptable sustainability/incentivization o...2024-03-13T14:33:03ZGeorg KoppenWrite a proposal for acceptable/unacceptable sustainability/incentivization of relay operationsFollowing the ATOR incident we should write a proposal about what we expect from schemes claiming to enhance the sustainability of relay operations by providing (a bunch of) incentives. For some recent blog post around this topic, see: h...Following the ATOR incident we should write a proposal about what we expect from schemes claiming to enhance the sustainability of relay operations by providing (a bunch of) incentives. For some recent blog post around this topic, see: https://blog.torproject.org/tor-network-community-health-update/GusGushttps://gitlab.torproject.org/tpo/web/community/-/issues/7[Content] Tier 1 and Tier 2 languages2024-03-13T00:06:58ZPili Guerra[Content] Tier 1 and Tier 2 languageshttps://torpat.ch/manual-localeshttps://torpat.ch/manual-localesemmapeelemmapeelhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42452Allow restoring bridge pass (Lox credentials) with the same invite2024-03-12T12:26:19ZhenryAllow restoring bridge pass (Lox credentials) with the same inviteWe want to support the following in Tor Browser:
1. A user redeems an invite to get new lox credentials.
2. Later, they remove the Lox bridges.
3. The user re-inputs the *same* invite.
In this case, we should restore their credentials ...We want to support the following in Tor Browser:
1. A user redeems an invite to get new lox credentials.
2. Later, they remove the Lox bridges.
3. The user re-inputs the *same* invite.
In this case, we should restore their credentials after step 3 using our Lox cache. Bypassing the Lox authority.
@donuts or @cohosh, do you see any potential problems with allowing this?henryhenryhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41919Add a message, tooltip or icon to explain letterboxing2024-03-11T15:49:36Zma1Add a message, tooltip or icon to explain letterboxingWhile we're trying to make the letterboxing appearance look more intentional, we may want also to let user easily access an explanation of what it is.
Possible (alternative or combined) approaches variously surfaced in parent #32324:
1...While we're trying to make the letterboxing appearance look more intentional, we may want also to let user easily access an explanation of what it is.
Possible (alternative or combined) approaches variously surfaced in parent #32324:
1. Informative tooltip when user hovers the letterboxing area
2. "?" shaped cursor, making the letterboxing area clickable to open the relevant manual section (or the options page if/when
#41916 gets implemented)
3. "?" button appearing somewhere in the letterboxing area when there's enough space, instead of making the whole area clickable.
/cc @ruihildt, @thorinma1ma1https://gitlab.torproject.org/tpo/core/torspec/-/issues/39Write a proposal about handling/rejecting unrecognized cells on circuits2024-03-07T16:51:36ZNick MathewsonWrite a proposal about handling/rejecting unrecognized cells on circuits> First, allowing parties to send unexpected ignored traffic opens side channels, so we must do something about it. And secondly, you must be Jon Postel for his Law to apply, and you're not. And thirdly, Postel's Law is more what you'd c...> First, allowing parties to send unexpected ignored traffic opens side channels, so we must do something about it. And secondly, you must be Jon Postel for his Law to apply, and you're not. And thirdly, Postel's Law is more what you'd call "guidelines" than actual rules.
To constrain side-channels, @mikeperry thinks and I agree that we should be more restrictive about accepting unrecognized cell types and formats.
We should figure out how this interacts with proposal 325 (packed cells), and we should make sure that we don't write something that precludes future extensions to the protocol.
My intuition favors an approach something like this, though of course it might be wrong:
* Exits accept any well-authenticated cell that the client sends.
* Clients and onion services reject anything that they do not recognize.
* To add new relay message types in the future, we can declare that the exit may only send them in response to the client sending them first (or some other signal). We can declare that onion services must advertise that they accept them in their descriptors.
I bet there will be a lot of corner cases.
Assigning to @mikeperry with permission.Mike PerryMike Perryhttps://gitlab.torproject.org/tpo/community/training/-/issues/141[Privacy Resilience Grants] Record and upload trainings for incoming Tor trai...2024-03-06T13:44:06Zraya[Privacy Resilience Grants] Record and upload trainings for incoming Tor trainerscc: @guscc: @gusrayarayahttps://gitlab.torproject.org/tpo/web/snowflake/-/issues/3Basic front-end development for snowflake.torproject.org2024-03-06T13:40:23ZAshish SoniBasic front-end development for snowflake.torproject.orgConvert the design( #2) into code for a new landing page. Using HTML, CSS, BootStrap 5.3.0v integrated with lektor.
TO-DOs
* [x] Code Section - 1 (get-snowflake)
* [x] Code Section - 2 (use-snowflake)
* [x] Code Section - 3 (donate-ban...Convert the design( #2) into code for a new landing page. Using HTML, CSS, BootStrap 5.3.0v integrated with lektor.
TO-DOs
* [x] Code Section - 1 (get-snowflake)
* [x] Code Section - 2 (use-snowflake)
* [x] Code Section - 3 (donate-bandwidth)
* [x] Code Section - 4 (faqs)
* [x] Add Navbar
* [x] Make Website Responsive
* [ ] Multilingual SupportAshish SoniAshish Sonihttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41188Implement Android-native Connection Assist UI2024-03-05T18:49:47ZdonutsImplement Android-native Connection Assist UIAs originally proposed in https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/29590, we should port a version of the flows and UI for Connection Assist (a.k.a. "smarter bootstrapping" or "mostly automated censorship circu...As originally proposed in https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/29590, we should port a version of the flows and UI for Connection Assist (a.k.a. "smarter bootstrapping" or "mostly automated censorship circumvention") designed in https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40781 to Android.clairehurstclairehursthttps://gitlab.torproject.org/tpo/core/tor/-/issues/11101Bridges should report implementation versions of their pluggable transports2024-03-05T15:17:58ZRoger DingledineBridges should report implementation versions of their pluggable transportsOur bridges now run a variety of pluggable transports. What if there's a bug in, say, the Scramblesuit implementation (like it appears there is)? If we fix the bug, how do bridgedb or the Tor clients know whether the Scramblesuit bridge ...Our bridges now run a variety of pluggable transports. What if there's a bug in, say, the Scramblesuit implementation (like it appears there is)? If we fix the bug, how do bridgedb or the Tor clients know whether the Scramblesuit bridge they just learned about is one of the new (updated) ones or one of the old (buggy) ones?
One option would be for Tor to include a version for each supported PT in its bridge (or extrainfo) descriptor, so if we turn out to not want to use certain versions for certain situations, we can do it.
Are there better options than this one?Tor: 0.4.9.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://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/network-health/metrics/tor_fusion/-/issues/3Make tor_fusion deployment on metricsdb-01 and add documentation to the readme2024-03-05T15:10:35ZHiroMake tor_fusion deployment on metricsdb-01 and add documentation to the readmeTime has come to make a tor_fusion deployment on metricsdb-01 to parse onionperf files. We should also document how the deployment process works and how the service can be maintained.Time has come to make a tor_fusion deployment on metricsdb-01 to parse onionperf files. We should also document how the deployment process works and how the service can be maintained.HiroHirohttps://gitlab.torproject.org/tpo/community/relays/-/issues/67EFF University Tor relay advocacy campaign2024-03-04T19:33:05ZRoger DingledineEFF University Tor relay advocacy campaignWe are collaborating with Cooper at EFF to help them run an advocacy campaign to get more Tor relays running in universities.
The campaign has several synergistic goals, including: increase capacity for the Tor network; help create a ne...We are collaborating with Cooper at EFF to help them run an advocacy campaign to get more Tor relays running in universities.
The campaign has several synergistic goals, including: increase capacity for the Tor network; help create a new generation of activist-users who understand Tor and want to help; test and refine our messaging about the value of running a Tor relay; make sure privacy and decentralization are better integrated into the curriculum at more institutions; help provide a focus and a lever for people to change policy toward privacy and human rights tools at their institutions; and build a list of high-profile institutions that are participating in the Tor network, to normalize the idea that everybody should do it and so we can leverage that list for our policy and comms goals.
This is the master ticket for tracking the roadmap and progress on the overall campaign.
* [x] (0) Have some sort of starting web presence to point at, e.g. a Tor gitlab ticket.
* (1) Organize, write, and/or improve guides or links for each of
- [x] (1a) "how to set up a relay" (https://community.torproject.org/relay/)
- [x] (1b) "why universities are great places for relays" (https://gitlab.torproject.org/tpo/community/relays/-/issues/72)
- [x] (1c) "how best to advocate for a relay at your university" (https://community.torproject.org/relay/community-resources/tor-relay-universities/)
- [x] (1d) "explanations to reassure university general counsel"
- [x] (1e) "suggested escalation path e.g. start with a bridge, then a non-exit relay, then an exit relay"
- Some starting points: https://community.torproject.org/relay/community-resources/, https://www.eff.org/deeplinks/2014/06/why-you-should-use-tor
* (2) Re-establish and strengthen relationships with existing university relay operators
- [x] (2a) Invite them to publicly join the campaign at launch
- [x] (2b) Answer all of their Tor questions and ideas over time, and use these interactions as a feedback loop to improve the above guides.
- [x] (2c) Learn what level of support they have at their uni: do they just do it themselves? Does the GC know? What do the sysadmins think?
- [ ] (2d) Connect them to their peers to strengthen the community
- [ ] (2d1) Cultivate a section in the Tor forum for this audience
- [ ] (2d2) Hold periodic university relay operator meetups
- [x] (2d3) Set up announce/newsletter mailing list
* (3) Put the campaign on the web
- [x] (3a) Have a central EFF campaign site, including the above guides/links, the names of amenable participants and institutions, etc.
- [x] (3b) Have an EFF lawyer on deck to reassure university lawyers. Prepare this lawyer for the questions they will receive.
- [x] (3c) EFF reviews the EFF Tor Legal FAQ to see if it needs any updates. (As of April 2023 Cooper says they have looked at it again and they are still happy with it.)
- [ ] (3d) Make sure the improved guides get onto the Tor community portal too.
* (4) Figure out a scalable and sustainable way to keep track of our contacts.
- [x] Start with a contact email alias with the five-ish of us on it, but very soon we will want something more workable than "past emails in our mailboxes" for being organized. Try not to invent too many new things, but also don't fall into the Google docs trap. A pad? A git repo?
* (5) With help from our EFA contacts, track which universities are Tor-supportive.
- [ ] (5a) Policy and culture: Are they ok with snowflakes on their network? bridges? relays? What are the *policies* (AUP, etc) about running tools like Tor on their network?
- [ ] (5b) Technical: Does Tor as a client work on their network in practice? Are the Tor websites (www, gitlab, etc) reachable?
* (6) Recruit new university relay operators, choosing them by:
- [x] (6a) Direct contact from existing relationships
- [ ] (6b) Picking the good candidates from step 5
- [x] (6b) Drive interactions from people discovering the campaign site
- [x] (6c) Spread the word at academic conferences and events
- [x] (6d) Do Tor seminars and guest lectures at key (tipping point) institutions
* (7) Publicize the ongoing successes
- [ ] (7a) Pick out some good ambassadors and amplify them
- [ ] (7b) Reward (swag!) and highlight the Tor-positive institutions
- [ ] (7c) Visualize and understand our progress using network health tools (https://gitlab.torproject.org/tpo/community/relays/-/issues/73)
- [ ] (7d) Become as open with our data as we can, modulo individual privacy
- [ ] (7e) In particular, highlight successes on Tor's community portal too
- [ ] (7f) Feed everything back into step 1
* (8) Unsorted bonus items for later phases
- [ ] (8a) A stock "Tor and Education" presentation that people can use to drive their own advocacy
- [ ] (8b) Curriculum content for professors (most every security class these days has a Tor module, and they vary widely)
- [ ] (8c) Other ways to help, e.g. run a Conjure station at your uniRoger DingledineRoger Dingledinehttps://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/126Research about designing an armored bridge line sharing URL format2024-03-04T15:32:16ZshelikhooResearch about designing an armored bridge line sharing URL formatTor's bridge line format is well suited for professional developers and power users on desktop environments. However, for other users the current bridge line does not work so well because:
1. The bridge line contains white space and oth...Tor's bridge line format is well suited for professional developers and power users on desktop environments. However, for other users the current bridge line does not work so well because:
1. The bridge line contains white space and other special characters that could make it hard to copy and paste correctly.
2. When the bridge line was corrupted, the client software can neither detect it, nor correct it. This results in user confusion as the corrupted bridge line results in silent error.
3. User tries to edit the bridge line without understanding how it works internally. This results in inconsistency between how the user expects a bridge line to work and how it actually works.
This ticket tracks the research and discussion about creating a new bridge line format specialized in sharing to address the issues mentioned.
Let's make some initial discussion before I write the full spec and write a reference implementation.
## Goals and non-goals
This armored bridge line format will try to:
1. auto detect/auto correct error occurred during transmission. Give the user explicit feedback when the bridge line is corrupted and avoid silent errors.
2. improve its operating system integration, allowing the user to click on the armored bridge line and be redirected to a bridge line recipient application.
3. avoid any characters or design that could make it harder to transmit the bridge line correctly.
4. signal user not to modify the shared bridge line by intuitively
It won't:
1. try to replace the current bridge line format. It is used to share bridge lines, and original bridge line format will still be accepted by all Tor applications and shown to users by default. The current bridge line format will still be the way bridge configurations are represented.
2. prevent users from editing bridge lines. Users still will be able to edit the bridge line once it is decoded from armored format.
3. prevent the bridge line from being censored or detected by authority.
## Expected Usage Context
This armored bridge line design will be used exclusively for sharing.
Specifically:
1. On Tor Browser, there will be a share bridge line button, when clicked, an armored bridge line will be converted from an ordinary bridge line, and shown to the user as plain text and QR code.
2. The user support team will share an armored bridge line generated from Tor Browser or command line tool to users requesting a bridge when appropriate.
3. Users can share armored bridge lines with each other.
4. Tor client implementations MAY support armored bridge line input. It is optional since this design is targeted toward ordinary users, and Tor Browser already supports converting bridge lines between different forms with command line tools. Advanced users can just use command line tools to convert bridge lines between its different formats.
## Internal design (for discussion)
The 2 way convention between armored bridge line and ordinary bridge line is through a sequence of reversible transform steps. Some of them are optional(under discussion), and may or may not be included in the final design. There are no dynamic or skipable step in the final version of the design.
### Compression (optional)
A compression like 7 bit UTF8 can be used to reduce the length of the final url string.
It will however make conversion more complex to implement.
### All or none transform (optional)
A all or none transform(AONT) like [SAEP+](http://crypto.stanford.edu/~dabo/abstracts/saep.html) can make sure the final output is completely random looking, polymorphic without any resemblance of underlying data.
This ensures:
1. Data are covered by checksum(see SAEP+ design), so any corruption will be detected.
2. Because data are encoded differently each time, if the final output contains a censored keyword, the user can just try again.
3. there will be less observable patterns in the final URL, preventing users from attempting to modify or interpreting it. The users will need to use a supported application to process the armored bridge line.
4. (less of a concern for Tor ecosystem) prevent client implementation from ignoring the checksum and process anyway.
This is a complex transform step.
### Checksum (if All or none transform step is not used) (optional)
Use a CRC64 or SHA-3 to generate a checksum to detect corruption.
This step should be skipped if AONT step was used.
### Forward error correction (optional)
Split the data into chunks and use Reed Solomon coding to encode the data and generate recovery shreds.
When the bridge line is corrupted, forward error correction attempts to repair content directly, without asking the user to try again. This non-interactive repair makes it easier for the user to get the bridge line working, without asking and waiting for assistance. Some environments like bad email clients/line breakers corrupt the content each time it processes it, retry itself won't work and frustrate users.
This is a complex transform step.
### URLSafe base64 encoding without padding + concreted
URL safe base64 encoding without padding will convert the binary result of previous steps into a URL safe string. If there is more than one shard of contents, they will be concreted with ~ symbol, which is URL safe and not used by URL safe base64.
### URL Prefix
The final string will be prefixed with either `bridgeprefix:?` or `https://bridgeprefix/#` to allow it to be clicked and be redirected to Tor client application by operating system.shelikhooshelikhoo2024-03-08https://gitlab.torproject.org/tpo/core/tor/-/issues/40578Let bridge users choose to only reach their first working bridge2024-02-28T17:55:43ZRoger DingledineLet bridge users choose to only reach their first working bridgeWe have some users in Russia who collect dozens or hundreds of obfs4 bridges, and when they start their Tor, it bursts out dozens/hundreds of connections at once to try to reach every single bridge and see which ones are working. That is...We have some users in Russia who collect dozens or hundreds of obfs4 bridges, and when they start their Tor, it bursts out dozens/hundreds of connections at once to try to reach every single bridge and see which ones are working. That is loud, wasteful, and maybe even dangerous.
In Snowflake (https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/28651) we are heading toward a world where Tor Browser users have k snowflake bridge lines, one per destination bridge, in order to scale up and improve resiliency. But the Snowflake people worry that doing more than one-ish Snowflake connection will be wasteful (since each connection involves a domain front, a stun connection, a webrtc handshake, etc) and also it will stand out on the network. So they are considering having Tor Browser choose just one Snowflake line at random for each user, which helps with the scaling but it discards all the resiliency features that we would be so close to getting.
I think the answer in both these cases is that we want an option in Tor that makes you only try to fetch bridge descriptors from the bridges you actually hope to use.
I expect the main two parts of this change will be:
* When considering launching a bridge descriptor fetch, decide if you would call this bridge one of your primary guards if it worked, and if not, don't fetch.
* As soon as any bridge fails, immediately go through and see if you need to launch any new descriptor fetches (because otherwise you could end up in a situation where your existing bridges failed and you aren't trying any new ones yet).
(I do think we want to retain the existing "try them all" behavior as an option too (maybe even the default? that's a decision we should make), first for the people who use bridges for connectivity because it gives you the best connectivity, and second because we use the "try them all" functionality in e.g. bridgestrap.)Roger DingledineRoger Dingledinehttps://gitlab.torproject.org/tpo/core/arti/-/issues/1257Upgrade to educe 0.52024-02-28T14:33:54ZNick MathewsonUpgrade to educe 0.5Educe 0.5 is out; we should upgrade eventually. There are compatibility issues.Educe 0.5 is out; we should upgrade eventually. There are compatibility issues.Ian Jacksoniwj@torproject.orgIan Jacksoniwj@torproject.orghttps://gitlab.torproject.org/tpo/web/donate-neo/-/issues/19Stripe webhook delivery issues for https://backend-services.donate-review.tor...2024-02-27T15:38:56ZanarcatStripe webhook delivery issues for https://backend-services.donate-review.torproject.netI (as a Stripe user) received a notification from Stripe that it's having trouble with one of the web hook endpoints:
> We've had some trouble sending requests in test mode to a webhook endpoint associated with your Tor Project Donation...I (as a Stripe user) received a notification from Stripe that it's having trouble with one of the web hook endpoints:
> We've had some trouble sending requests in test mode to a webhook endpoint associated with your Tor Project Donations account. Stripe sends webhook events (https://stripe.com/docs/webhooks) to your server to notify you of activity in your Stripe account, such as a completed payout or a newly-created invoice.
>
> The URL of the failing webhook endpoint is: https://backend-services.donate-review.torproject.net/stripe/webhook/
>
> You (or someone on your team) configured your Stripe account to send events to that URL. You can change your account's webhook endpoints from the Dashboard (https://dashboard.stripe.com/b/REDACTED?destination=%2Fwebhooks).
>
> In most cases, a failing webhook does not affect your payments or payouts. However:
>
> - If you use subscriptions we rely on your webhook endpoint (https://stripe.com/docs/billing/subscriptions/webhooks#understand) to notify you of new invoices. These invoices may be delayed for up to three days if your endpoint is unable to successfully receive them.
>
> - If you use Checkout and rely on the checkout.session.completed event as part of your purchase fulfilment process (https://stripe.com/docs/payments/checkout/fulfillment#webhooks), you should review your completed payments to ensure you have fulfilled all recent purchases.
>
> We've attempted to send event notifications to this endpoint 336 times since the first failure on February 22, 2024 at 6:46:03 PM UTC. If this endpoint is important to your application, please try and fix the issue. If you do not need this webhook endpoint, you can remove it from your Stripe webhook settings (https://dashboard.stripe.com/b/REDACTED?destination=%2Fwebhooks). We will stop sending event notifications to this webhook endpoint by March 2, 2024 at 6:46:03 PM UTC.
>
> Here is the summary of errors we received while attempting to send webhook events:
>
> - 336 requests had a TLS error, indicating that Stripe was unable to establish a secure connection with your server. You can generate a detailed analysis about your host's TLS configuration (https://ssllabs.com/ssltest/analyze.html?d=backend-services.donate-review.torproject.net:443&hideResults=on) to identify common errors.
>
> You need to return any status code between HTTP 200 to 299 for Stripe to consider the webhook event successfully delivered.
>
> For more details on these errors and to review your account's recent activity, you can find the full set of events (https://dashboard.stripe.com/b/REDACTED?destination=%2Ftest%2Fevents) and request logs (https://dashboard.stripe.com/b/REDACTED?destination=%2Ftest%2Flogs) on the Dashboard.
>
> For more in-depth information on how to use webhooks, we recommend reviewing our documentation (https://stripe.com/docs/webhooks).
>
> Yours,
>
> The Stripe team
@lavamind @stephen any idea what this is about?
I wonder if this is something that has been happening all along and I'm just noticing now that I have a dev account, or if it's a regression related to our token rotation (tpo/tpa/team#41530)?stephenstephenhttps://gitlab.torproject.org/tpo/community/l10n/-/issues/40125Add documentation section about RTL for developers2024-02-26T19:28:02ZemmapeelAdd documentation section about RTL for developersWhen we release translations RTL some questions are always repeated, and it would be nice to have a documentation that developers can read, with examples and best practices. Also with screenshots to understand the common problems.When we release translations RTL some questions are always repeated, and it would be nice to have a documentation that developers can read, with examples and best practices. Also with screenshots to understand the common problems.emmapeelemmapeelhttps://gitlab.torproject.org/tpo/network-health/metrics/networkstatusapi/-/issues/52Rework proxying logic to VictoriaMetrics2024-02-19T16:16:51ZMattia RighettiRework proxying logic to VictoriaMetricsCurrent proxying logic is not actually proxying the request to VictoriaMetrics, but rather issuing another request from NSAPI to VictoriaMetrics and then streaming the response back. That is probably the reason why it's not responding wi...Current proxying logic is not actually proxying the request to VictoriaMetrics, but rather issuing another request from NSAPI to VictoriaMetrics and then streaming the response back. That is probably the reason why it's not responding with large timewindows (+20d of data).
What should actually happen is that NSAPI should make the appropriate changes to the request headers from the original user and pass it on to VictoriaMetrics, creating two streams of data like the following VM -> NSAPI -> User.
A good implementation example is the [`httputil.ReverseProxy`](https://go.dev/src/net/http/httputil/reverseproxy.go) in Go's stdMattia RighettiMattia Righettihttps://gitlab.torproject.org/tpo/anti-censorship/lox/-/issues/28Set daily max bucket distribution and adjust other settings for production2024-02-15T16:52:09ZonyinyangSet daily max bucket distribution and adjust other settings for productionWe likely need to decide on an upper bound of buckets that can be distributed each day so that we don't run out of open invitation buckets. We currently have buckets being distributed to k users before a new bucket is used but if buckets...We likely need to decide on an upper bound of buckets that can be distributed each day so that we don't run out of open invitation buckets. We currently have buckets being distributed to k users before a new bucket is used but if buckets are continuously requested, we will eventually run out of buckets each day. These variables should be part of a configuration file for Lox.Lox Ready for Open Testing Callonyinyangonyinyanghttps://gitlab.torproject.org/tpo/community/l10n/-/issues/40023Update documentation for developers2024-02-14T10:15:48ZemmapeelUpdate documentation for developersMaybe it was lost along with trac, maybe it was never there...
Lets update the https://gitlab.torproject.org/tpo/community/l10n/-/wikis/Localization-for-developers wikipage with resources for developers
- [x] promote the use of the [Tr...Maybe it was lost along with trac, maybe it was never there...
Lets update the https://gitlab.torproject.org/tpo/community/l10n/-/wikis/Localization-for-developers wikipage with resources for developers
- [x] promote the use of the [Transifex sandbox](https://www.transifex.com/otf/tor-project-sandbox/dashboard/)
- [ ] explain the situation of each of the languages, and how to see updates
- [ ] [restrict which languages are translation targets](https://gitlab.torproject.org/tpo/community/l10n/-/issues/40020)emmapeelemmapeel