diff --git a/000-mass-deletion-improvements.md b/000-mass-deletion-improvements.md new file mode 100644 index 0000000..c68c675 --- /dev/null +++ b/000-mass-deletion-improvements.md @@ -0,0 +1,60 @@ +# Increase deletion rate limit + +- Proposal: (link to GitHub PR related to this proposal) +- Discussion: (link to GitHub issue related to this proposal) +- Authors: + - Ada Cable(@adacable, adacable) + +- Review Manager: TBD (this will be filled by the review manager) +- Status: Open + +## Introduction + +The current rate limit on deleting your own tweets is 50 + +## Motivation + +"Tweet delete" Applications are popular- They allow people to retain their account, followers, and other elements, while removing old content which may no longer represent them, or which can be taken out of context + +They're used by people when they apply for a new job, may come into the public eye, have a life circumstance change, or other event where they may wish to remove content they don't remeber writing(which may be more than a decade old). A variety of popular options exist both hosted and as 'scripts', either deleting tweets as people go(setting a "one week expiry" or deleting en masse based on a twitter archive file). + +These applications may need to delete thousands of tweets quickly, for legitimate use cases- for example, if someone is applying for a new job tomorow, and has 15 years of use equating to possibly tens of thousands of tweets on their account. These applications are also favoured by power users, and high profile users, who have a greater risk of public humilation by having their tweets taken out of context. + +The former API had effectivley no rate limit on the delete call, but as far as I can tell effectivley rate limited it by being slower- leading people to write multithreaded delete scripts. + +I think it's also good practice compliance wise- while you have a month to process GDPR/etc data deletion requests, or people can instantly delete their entire account, allowing people to control their data without forcing them to do that is both good practice and can increase public engagement. + +## Proposed solution + +Two options are proposed + +- The simple way is to remove the rate limit on deleting tweets(as was implemented previously), or increase it significantly(500/15m block will give deleting 100k tweets a 50 hour deletion- with 100k requests. This is 10x faster than the current system.). +- The more developer intensive but lower overhead way is an endpoint that allows deletion of multiple tweets in one request on the DELETE/2/tweets(as one can with GET /2/tweets, but for destroying rather than getting) reducing the number of requests and overhead. Allowing 50 requests/15m and 100 tweets/request would give 20000 tweets/hour, or 5 hours to delete 100k tweets(with 1000 requests- much more efficient than the first option). This could have a higher rate limit, if the backend is easily stressed, maybe 5/15m reqests to delete 100 tweets each- 100x faster than the current system. + +Both of these improve the developer experience, and while the first is simpler to implement for both twitter and third party developer, the second is preferable for the third party because it's faster, and for twitter because of a lower overhead. + +The first solution is on the face of it cleaner(it requires no changes to the actual api, just the rate limiting) but the second allows + +Allowing people to delete their own publicly facing data as fast as practical is obviously preferable from a data protection standpoint, and the place to combat the threat of an attacker gains authenticated api access is not effectivley prevented by rate limiting. + +The first is not more efficient than the current system(indeed, it would result in more densley packed requests), however the second significantly reduces the number of requests to the API by people deleting their tweets. + +## Detailed design + +A rate limit change does not significantly change the current API. + +Implementing DELETE /2/tweets as well as DELETE /2/tweets/:id is a good model- It mirrors GET /2/tweets but with DELETE, and is IMO already expected behavior. This is the better option, but requires more implementation time for twitter staff. + +Having differing rate limits for DELETE /2/tweets/:id(deleting a single tweet) and DELETE /2/tweets/ (deleting multiple tweets) would be complex to implment, explain and monitor- but could be done if there are worries about backend stress. + +## Compatibility, breaking changes and migrations + +No breaking changes, though significant advantages for developers who use the new rate limits or the DELETE /2/tweets. The time to upgrade code to batch tweets in a request should be minimal, however simply increasing the rate limit is obviously simpler. + +With a rate limit increase, well implemented clients should adjust automatically, even in deployment, without any changes. + +Updating client lidbaries for the second one will be more work, however it's similarity to GET /2/tweets should speed things along significantly. + +## Alternatives considered + +This proposal discusses two alternatives. The second is the better from an external perspective, but twitter inc will have different priorities to me. diff --git a/proposal-template.md b/proposal-template.md deleted file mode 100644 index a6dc3d1..0000000 --- a/proposal-template.md +++ /dev/null @@ -1,63 +0,0 @@ -# Proposal title - -- Proposal: (link to GitHub PR related to this proposal) -- Discussion: (link to GitHub issue related to this proposal) -- Authors: - - Author 1 (Twitter, GitHub) - - Author 2 (Twitter, GitHub) - -- Review Manager: TBD (this will be filled by the review manager) -- Status: Open - -## Introduction - -Briefly describe what the proposal is about. This introduction is a short, one-paragraph vision statement for the proposal. - -## Motivation - -What problem or problems is this proposal looking to address? - -For changes or modifications to the current API design, provide one or more examples of how a similar solution can be achieved within the current design. Practical examples are an effective way to visualize and reproduce (if possible and needed) the problem you’re trying to address with this proposal. - -If you are introducing new functionality, explain in detail what are the advantages and benefits compared to the current design. This section should answer the following questions: - -- Does this proposed solution introduce new usage patterns? What learning curve should developers expect and why? -- Are there similar API designs (e.g. RFCs, peer platforms) implementing a similar solution? - -## Proposed solution - -What is the intended solution or result? If the proposal is introducing new functionality, provide a detailed description and add examples as needed. For example, if the proposal aims to change the payload structure, provide an example request and response payload. If the proposal seeks to change the route structure of request fields or headers, provide a comprehensive list in order to describe the widest possible range of circumstances the proposal will apply to. - -This section should answer these questions: - -- How would this solution look like from the perspective of the developer? -- How is this proposed solution improving the developer experience? -- How is this proposed solution cleaner than the current solution? -- How is this proposed solution safer than the current solution, in terms of data protection? -- How is this proposed solution more efficient in terms of data requested and retrieved? - -## Detailed design - -How would your proposal change the API design? This section should be used as the technical representation of your proposal. In this section, you detail how the grammar and ergonomics of the API should be changed. For example, if you are introducing a change in the route structure, you should explain how the route structure should be applied to each entity requested. If you are planning to add a field, expansion or payload section, explain how the behavior will be coherent across similar requests. - -This section should contain all the necessary information with a level of clarity that can allow the Twitter team to implement this feature. - -## Compatibility, breaking changes and migrations - -Will this proposal require developers to change their current implementation? Your proposal should articulate how developers may implement the new feature. Some changes will require developers to change their implementation, and that is considered a breaking change. If your proposal changes the behavior of any currently implemented feature of the API design, you should clearly state that. - -In any case, this section should always answer these questions: - -- How will this proposal work with existing developer implementations? -- If we implemented this proposal today, what apps will require a change, and what apps will break without this change? -- How can developers discover and quickly implement this proposed design? -- How will SDK or client libraries maintainer need to implement or support this feature? - -## Alternatives considered - -Describe what other alternatives exist, or what other solutions you considered. For each alternative, your proposal should describe how this solution improves the Twitter API platform. There may be cases where certain solutions may offer a wider range of benefits than your proposal, and that’s okay. This can be the case of a solution that’s technically superior, but that may take more time and effort than what you’re proposing. In that case, explain why how your proposed solution can be a reasonable tradeoff. - -This section should answer these questions: - -- What happens if we do nothing? -- What alternatives did you consider? What are the benefits and tradeoffs of your proposed solution compared to this alternative? \ No newline at end of file