TornPal Response

This will be a long read, with lots of nuance, detail and can get quite technical. I will try my best to keep it straightforward, and will provide answers as and when. You are of course entitled to ask anything, it is a public forum, but I will be responding to questions, not unfounded allegations or opinions, or anything already answered. Given I am quite limited on time between a personal issue, work and other responsibilities, it may take some time to do all of the responses, so bear with me.

This may be broken into several posts and reference material - when I first post this it may take me a few minutes to tie everything together if so with links and whatnot.

What data does TornPal collect?

For reference, the "selections" I mention here are based on the Torn API selections, check the bottom of the "Selection Access Levels" for more information on key levels etc and I will go through what each is used for. If you use your own API key on these selections at each level, you can see what is visible.

This is meant to be raw selection data. Explanations on how data is used is further down. All API requests from TornPal will be commented as TornPal.

TornPal may be used with any of the 4 main key levels, a public key, minimal key, limited key or full key. Some features may require higher key levels due to how a feature would work. Custom keys do not yet work as a relic of how TornPal was set up early on and I needed to get things moving quickly, so it was easier to make assumptions about the key based on level, than implement more advanced logic to iterate through keys to find the the ones with the correct combination of permissions for a particular task. This is likely to change in future to be accepted, but I have no date yet due to other commitments.

The overarching principle here is this: if another user can see something about you, such as your name, bazaar, display case etc - then this is not private data. Examples of private data, which cannot be obtained from the API key of anybody else (or a public API key you have provided), is things such as battle stats or bypassing the daily "personalstats" cache etc.

Personal Details

All Keys At Login

/key/ - Used to determine the access level the key has, so I am quickly aware the type of key it is (ie custom, public, minimal, limited or full) and who the key belongs to.

/user/basic - Used to get your name to fill out my Users table so it can greet you by name

/company selections - profile, timestamp

Public Keys (About You)

/v2/user selections - discord, personalstats, medals, profile, bazaar, timestamp, forumposts, forumthreads

/v2/faction selections - basic, members, timestamp, rankedwars

/company selections - profile, timestamp

Public Keys (About Others)

/v2/user selections - discord, personalstats, medals, profile, bazaar, timestamp, forumposts, forumthreads

/v2/faction selections - basic, members, timestamp, rankedwars

/company selections - profile, timestamp

Minimal Keys (About You)

/v2/user selections - discord, personalstats, medals, profile, bazaar, timestamp, forumposts, forumthreads, workstats, bars

/v2/faction selections - basic, members, timestamp, rankedwars

/company selections - profile, timestamp

Minimal Keys (About Others)

/v2/user selections - discord, personalstats, medals, profile, bazaar, timestamp, forumposts, forumthreads

/v2/faction selections - basic, members, timestamp, rankedwars

/company selections - profile, timestamp

Limited Keys (About You)

/v2/user selections - discord, personalstats, medals, profile, bazaar, timestamp, forumposts, forumthreads, workstats, bars, battlestats, stocks, attacks, hof

/v2/faction selections - basic, members, timestamp, rankedwars

/company selections - profile, timestamp

Limited Keys (About Others)

/v2/user selections - discord, personalstats, medals, profile, bazaar, timestamp, forumposts, forumthreads

/v2/faction selections - basic, members, timestamp, rankedwars

/company selections - profile, timestamp

Full Keys (About You)

/v2/user selections - discord, personalstats, medals, profile, bazaar, timestamp, forumposts, forumthreads, workstats, bars, battlestats, stocks, attacks, hof, log

Exceptions: "Log" is used against my own API key to track incoming and outgoing payments for item deposits. "Log" is available for the research purposes section of my data policy - but this has not been used to date and there is no current plan to use it, but it was implemented in case a solution was needed to do research with trustworthy partners where I could gather and anonymise the data to investigate, for example, new crimes, OCs etc.

/v2/faction selections - basic, members, timestamp, rankedwars

/company selections - profile, timestamp

Full Keys (About Others)

/v2/user selections - discord, personalstats, medals, profile, bazaar, timestamp, forumposts, forumthreads

/v2/faction selections - basic, members, timestamp, rankedwars

/company selections - profile, timestamp

Note on "forumthreads" and "forumposts". These selections are not routinely used except where doing data projects to retrieve public forum posts. The actual function that does this selects a random API key which could be any level is would be very unlikely to be your own key since it doesn't matter which it uses, but will only retrieve public information.

Only profile, bazaar and timestamp are requested in all API calls. The others regular requests do so periodically for yourself, which by default is:

[image: uploads.glasnost.dev]

Note that for data requested using your key about others, or where you are using a public or minimal key for yourself, this is a little different in that the "hof" and "personalstats" are requested once per day for that player at any time, and will not request it again until after 1am TCT due to the daily update cache making it pointless requesting any more frequently as it will not change.

Factions note: Due to a copy and paste error - there were a few requests sent out requesting "crimes" from factions if the faction leader or co-leader was registered on TP. This was an error, and as the program was not expecting the data as that function was not even started or built, it was never stored anywhere.

Global Details

All keys

/torn selections - timestamp, stocks, items, bank, companies, itemdetails

This updates the items available in Torn, the market values of items, bank interest rates and the Torn server time

/market selection - pointsmarket, timestamp

As above, updates the points currently for sale.

/v2/market/itemmarket selections - 'Bonus' => Any

/v2/market//itemmarket selections - n/a, just requests item market listings

/v2/torn/hof - category "workstats"

/v2/forum/threads - no selections for this, but usually sorted oldest to newest to gather all public forum threads

/v2/forum selections - posts

Neither of the above are routinely used, and only for occasional public data projects.

More following...

What does TornPal do with the data?

How the systems interact can get technical - I want to avoid this as it'll either be gibberish to most or boring to anyone who regularly works with databases and queue systems. If there is a particular question to be addressed from a tech perspective, ask in the thread and I'll try cover it best I can.

I will need to break this down differently than above to make it slightly more readable and understandable, as data interacts together sometimes (ie pulls the company star rating from a different place than the player details who works for that company).

"Global" Data

The easy part is the "Global" data as I categorise it. The market selections is to retrieve a list of all items, the item type and market value of the items, so when you visit the markets page on the website, it can show the "Market value" as a comparison to the item market and/or bazaar item prices. It is a benchmark. There is also a (currently partially broken) RW scanner, which checks the RW item market listings where they have any bonus. This is public without login here:

https://tornpal.com/markets/search/weapons

Points market data is used to calculate the price of points. The data from the Torn API is updated daily, meaning it is hard to keep up with price swings. This is requested, and then I use a weighted average of the cheapest few listings to arrive at a more accurate points price.

Forums threads, as described, are not routinely requested, but are used in data projects etc. This is not displayed in TornPal at this stage as it would be a huge number of requests for likely less utility for people using TP, and was last updated some time ago (at least 2-3 months from recollection).

HoF is more complicated for the global data. The only global HoF requested at present is workstats - which is the "Total" of your working stats. This data is public for all, and is how I show the total working stats on the profile of a person. This does not give access to a breakdown of the stats.

The HoF working stats is used as part of the Company Recruitment tool I offer, which is free (it was originally planned to be paid, but I decided against this eventually although I am yet to update the "temporarily free" banner). This tool does not use the "workstats" from personal data - more on that later.

https://tornpal.com/services/companyrecruitment

Faction Data

This is relatively new in the past week or two to TornPal. At present, we collect data on the members of each faction, the ranked wars they have been in and the "basic" selection (things like are they in a war right now, faction rank, leader ID, how many members, respect etc - the public information available).

This data is not yet available on TornPal - however it is used indirectly in a test at present with limited testing/beta users to determine if a faction is in a ranked war, and who the opponent is, then lists their members (akin to what you see in Torn). This then uses the ffscouter tool to guess the stats of the opponent (another tool discussed later).

You can see a gif of this dashboard in action which I sent to a developer on Torn (Pete)

This dashboard mostly does not use TornPal. It loads the basic faction data of the opponent and the members, but then will make browser-side requests. This means that TornPal is not actually requesting the data, your own browser is requesting it and TornPal does not see this request or take any data from it. This uses the API key you used to log into TornPal with for that session, so is only ever your own key and TornPal never sees/handles this data.

There are future plans to build a tool to help faction leaders, such as make quick lists of people with revives turned on, people not in OCs over a particular amount of time, people in OCs which are too easy or hard, people with missing items in OCs etc. This has not yet been developed on TornPal.

Optional Data Sharing:

When you sign up to TornPal, data sharing preferences (which I hope to release soon) are off. This means, if the data is private, it is not visible to anybody else unless you explicitly choose this (not available yet, so it all remains private). For this feature when it is released, you will need to click a button which will set out which data you share. For example, you will be able to share initially your bars (energy bar at first) and battle stats with either nobody, just your faction leader and co-leader, or your whole faction. If you do nothing, nobody except you can see this - any buttons which change this will be labelled as such.

Personal Data

Probably the most complicated section. The actual data requested is set out at the top, so I will focus on the products, services and pages where things are visible or are used, as some data is rarely used, some is used all the time.

Stocks -> Stock Portfolio and Stocks -> Stock Benefits & ROI (free)

This uses the "stocks" selection from the user requests. These pages are the only place stocks data is used on TornPal, and is only ever visible to you. It shows you your current portfolio in the first, and the second lists the financial related stocks to determine the best ROI possible. This is where the "points" and "items" information from global is also used to calculate a dollar value of items or points that may be received from stock payouts.

Stock Portfolio

Stock Benefits & ROI

Services -> Company Recruiter (free)

This uses all-public data about a user and searches by or has options to search by:

Total Working Stats (from HOF), Level, Current Job (screenshot of options), company rating (from company selection earlier), trains received (from public personalstats selection) and trains received last 30 days (by comparing personalstats now vs personalstats 30 days ago). Sorting may be done by these fields, as well as activity streak (also public personalstats fields).

Output results example

Services -> Faction Recruiter

Long list of search parameters as shown here, here and here

These factors are from publicly viewable personalstats: level, age, property, hours played, xanax taken, donator status, networth, RW hits, offences (crimes), OC completed, respect earned. Variations exist for searching the same for the past 30 days too.

Faction search filters are taken from the public factions data gathered.

Sorting is done by the same parameters - battle stats noted below is different.

The battle stats search parameter and sort parameter does not search actual battle stats. It uses the battle stat estimates instead. FFscouter is generally quite accurate below 10bn stats or so, therefore if anyone who has never used TornPal before would like I can show how this would work.

Note on the battle stats search field

Services -> Chain Lists (free)

This uses battle stat estimates to try and calculate the FairFight you will receive when chaining.

Search parameters

Results page

Sort Results By

The two buttons above provide presets for the options to make it easier, the above results page uses the "Levelling List" one.

Services -> Order Losses with Nebula (paid)

This service is used to order losses from Nebula using an automated system we set up in partnership. To buy them you need account credit (covered later), and once this is done Nebula check for new orders and add it to their list.

The only information passed to Nebula is the ID of the person order/who the order is for, the amount ordered, the type ordered, and the finances of it (ie how much you paid, how much TP takes in commission, how much they get) so we can both cross check all details at every stage.

Using the "personalstats" selection, the following popup is also available to help people know what merits they are missing that losses might help with. I do not use the actual merits endpoint for this.

Merits Available

Nebula Panel

The Nebula panel which is not public, is the same details as sent to them in the order so they can check the details on TornPal matches their own if there is an issue, as well as a button to disable accepting orders and a list of Nebula staff as nominated by GenShinigami who can access the orders.

Services -> Arrests Finder (retired/paid)

This is a closed service. However, I will run through the details still.

Myself and Omanpx attempted to create a tool that when looking at your public personalstats data, will attempt to estimate your arrest warrant for Detective Agencies. However, it was too inconsistent to carry on with so was discontinued. It would select targets and attempt to find the highest bounty available and show:

Name, ID, estimated battle stats, estimated reward, est reward range and the last known jail time.

Screenshot

The last known jail time is detected by two methods; daily personalstats updates and faction lists.

Personalstats updates have a counter when you are jailed. If this is incremented, then it considers you jailed at some point recently and resets the warrant.

The faction update is similar, as faction member lists return the current user status (ie hospital, jail, okay etc). If a user is spotted in jail, then it is also considered to be a jailed person, and their warrant is reset.

The tool was unreliable as with only daily personalstats updates and fast busts in jail, many people were jailed and bailed before we seen it and too many targets were duds.

Item Markets & Bazaars -> Item Market (free)

There are two parts. Firstly the home page lists items in Torn, their market value, type etc. This data is from the /torn/items selection above:

Screenshot

Clicking on any item brings up the market search part of this shown below:

Screenshot

This data is gathered from the bazaar selections above (public data) for a user to show what they currently have for sale, as well as the item market selections, then lists them by the cheapest offerings across both and notes the potential resale value on the item market for bazaar items.

There are two caches in play here. The first is the Torn cache, which is 30 seconds. Then TornPal also has a cache of 30 seconds, meaning from the moment an item is listed to the moment is shows in this API endpoint will be 60 seconds assuming TornPal rescans the bazaar at the perfect second or the user triggers a manual refresh in TornPal settings.

Weav3r's script uses the TornPal API to display the same data, you can see this yourself without an API key:

Actual script API data (Xanax)

Screenshot for Xanax items

Traders can opt-in to frequent scanning, so they will be prioritised for bazaar scanning more often. This helps if they are regularly opening/closing their bazaar and want to be listed quickly. This is optional and in the preferences panel.

Item Markets & Bazaars -> Market Bot (paid)

Market Bot is like the above item market, the only difference is instead of browsing this data manually, it alerts people to cheap items.

Screenshot - Example Alert

This data is from the item market section above being processed as it comes into TornPal, which compares the bazaar items (from the bazaar selection) listing and also shows item market listings (item market selection) for a price comparison, with "spread" representing a theoretical profit margin between them and a URL to go to the bazaar of the player.

The big differences between this market bot and the item market is firstly the bot lives on Discord, as implementing other solutions (ie websockets in the browser) is a lot more work and less flexible. The second is the delay. Market bot processes items as they come into TornPal one at a time, rather than looking at all bazaars at once like the API, so once it looks at an item, unless it is removed and added again later on, it will not show again. So it doesn't use a cache per se as it does not rescan the same data twice, so there is no need for a cache.

This does mean it is marginally faster than just hitting the TornPal API, but only by 30 seconds at most (should be an average of 15 seconds). The Torn cache is still in effect however, and this does sometimes cause listings to be skipped over until a review later on, as if somebody else requested the bazaar 5 seconds before it listed, the players lists, then I request the data immediately after, I will still see the cache data.

I have considered making a custom alert option, for example, "if x10 spoons are listed under $2,000, ping me" - but this isn't ready yet and I have only done some testing due to some complexities in the logic and time constraints making it hard to finish right now.

Item Markets & Bazaars -> Dollar Sales (free)

This also works on the data from the bazaars selection, and highlights the top 100 bazaars with $1 items listed, in order of the highest value descending.

Screenshot

Public Page

To support events through the year and give bazaar sellers more publicity (usually the reason for $1 sales), this page is public and open to all, but has no API endpoint yet (hopefully coming at some point).

Item Markets & Bazaars -> RW Search (free)

Also public, this lets users search across the item market and bazaars for RWs fitting certain criteria. It is still quite buggy, but it uses the same item market and bazaar selections as previously noted.

Page - No login

Screenshot

Results

All data here is from the bazaars, item details and item market selections, except where it displays the Name and ID of the seller for bazaar sellers which is from the "basic" or "profile" sections and is public.

Item details is used to retrieve the damage, bonuses etc where it is not available on a particular item, with the bazaar and item market used to find the listings available. Clicking a result will take you to the item market or the bazaar of the seller.

Account Credit

Not a feature per se, but I will cover it still.

TornPal does not accept cash in, only items. When an item is sent with the message "TornPal", and it is on the approved list, when I check my own API key every minute and see the transaction, I assign the market value of that item to the person who sent it.

Screenshot of page

This does not user any user data, as balances and other data are kept on TornPal's server and aren't a Torn piece of data.

Withdrawals are disabled, but I do process these manually when requested. However, the aim is to avoid being a trader and people sending me items only to withdraw at market value - this is an ongoing issue I need to think more about how to resolve before enabling withdrawals.

There is a referral scheme. So when people get a signup with their referral link as shown, a % commission from purchases will be given to the referrer. The person referred cannot see who referred them after the fact, and the referrer also cannot see who they have refered for privacy. The only visible information to confirm a commission payment is in the logs on this page.

Screenshot of commission payment

Account Credit -> Premium Subscriptions

This is where premium services are bought. Right now, 2 are on offer, Market Bot and Faction Recruiter. Market Bot is full so cannot be purchased. Arrests Finder, as mentioned previously, is no longer offered until we can find a way to make it more accurate.

Screenshot

No user data is on this page.

Leaderboards (free/public)

These are the public leaderboards:

Screenshot

Forum Karma Leaderboard

Other leaderboards can be browsed from the forum karma one, no login required.

All of the leaderboards, although different stats, operate on the same principle. They will use the public data from profile (forum posts, forum karma, age, competition) and public personalstats (the rest), and sometimes include your faction name (also from profile), and either display the top values in total, or top values as observed as a change over a certain period of time.

For example, forum karma ranks by karma highest to lowest as seen in the profile selection. Time played takes the value from public personalstats and ranks based on that.

These leaderboards are heavily cache for performance reasons, so typically 8-24 hours is normal, except the Halloween leaderboards which as they are static, are cached indefinitely.

Federal Jails is the notable exception. This updates when a person is seen as in federal jail from the profile->status selection (or if seen as the status in faction membership, triggers an update to the profile to double check). This then records your networth, hours played from public personalstats, level, faction, name, fed description and details from the profile.

Security Settings

This page tracks logins to TornPal using your keys, shows you which keys are on the account and shows Key Lock.

Screenshot

Key Lock: Enabling this will restrict your TornPal sign-ins to that key. So if you give another API key to somebody else, this cannot be used to log into TornPal but will log a failed attempt in the logs. This is to prevent another player with one of your keys signing in as you, and a lot of users utilise this feature thankfully. The only way to unlock this is messaging me in Torn to request it.

Keys: This is partially redacted so somebody logging in cannot get the whole copy of your API keys on the account, and shows which one you are logged in with and the date. If a key is paused, deleted, disabled etc, it will remain visible on here for 30 days before being deleted. Once a key is marked as inactive, it will not be used for any further requests, and remains visible to prevent anyone logging in with your key and trying to cover their tracks.

Recent Devices: This shows the best guess at the browser and OS used to log in, whether the login was successful, partial API and IP information and the date/time. Only partial information is ever provided. All information in this "Recent Devices" section is never shared except with Torn staff who request it via Torn. The unmasked data is not given to you as the user, only partial information, to prevent it being used if somebody managed to get access to your TornPal account.

Preferences

Not much here yet, but this is the planned destination for the privacy and data sharing system when ready.

Screenshot

The frequent bazaar checks simply acts as an opt-in to get rescanned more frequently if you are a regular bazaar seller and want to get listed faster.

Request immediate rescan invalidates all of your personal caches and will recheck all of your data again - useful to get something updated like bazaar listings or personal stats.

Admin Panel (not public - only Glasnost can view)

Screenshot

Recent Transactions

Active Subscriptions

Top Balances

Top Alerts

As you can see in Top Alerts, the probable errors are near the top so easy to delete from the statistics.

This is my own hub for keeping an eye on key details of the site, listing total keys, balances, subscriptions and so forth.

Further below, it lists the active subscribers, top user TornPal balances (money credited into TornPal) and the top item alerts through market bot that day (we had issues with Caches getting hugely inflated values, so it helps me to delete the massive outliers by checking it every day so the stats are accurate).

Public Profiles

This is where the bulk of data is displayed. Here is Omanpx's (used as an example with permission):

https://tornpal.com/profile/1906686

Most of the data seen, comes from 2 selections. Profile, and personalstats, both using only public data. The exceptions are battle stat estimates (discussed in ffscouter section) and the "bans" section, which is from recording federal jails (also as seen in the leaderboards for recent feds shown earlier).

All of this data, generally updated once or twice per day for active players, has the current values as well as the historical value shown from the past 7 and 30 days. Doing "last 24 hrs" isn't really feasible due to daily personalstats updates. By only updating the last 7 and 30 days options, players with limited or full keys are also not live broadcasting their stats using this if it runs irregularly and not in real time and it happens to update often at the exact moment you do something.

Work stats total is derived from the hall of fame as noted earlier.

I do as admin have a little more data on this page, Omanpx has approved me sharing this with some of the specifics blacked out:

Screenshot

As shown, I can see the highest level key (1 = public, 2 = minimal etc) on the account, the number of keys (first number is the active number of keys, second is total including disabled and awaiting deletion keys), as well as the account credit information. There is no way in the admin panel for me to view IPs, API keys etc of any other player but myself. This is an intentional design so that a stolen API key from myself does not grant too much power. In any case, I use Key Lock.

FairFight Scouter (FFScouter)

This was a feature remade from the original rDacted created and that separate controversy which was resolved (and checked by developers and multiple staff afterwards to find it was compliant).

I should note that a similar system is used by others to predict stats - this is my implementation of it as used by numerous scripts. It powers the battle stat estimates and fair fight estimates throughout TornPal. It differs from BSP but that is beyond the scope of this.

Like others, the user->'attacks' selection is used to pull attacks every few hours if you have a limited key present. It will then search for attacks where the following is true:

• The attack occurred in the last 24 hours
• It had a FF of more than 1 but less than 3 (so 1.00 and 3.00 are excluded)
• You are not in the top 1,000 HoF for battle stats (obtained by the user->hof selection at the top)
• The opponent is known (not stealthed)

Using your battle stats, I derive your battle stat score as shown on the wiki, and derived a battle stat score. A battle stat score is a proxy for your battle stats, but not exact, but is used to calculate Fair fight.

Then, using your battle stat score (which I store as "private") and the fair fight score, I use some math to estimate the battle stat score of your opponent, which becomes their "public" score.

This value is then recorded against your opponent as their public battle stat score in the database. By attacking them, your private score is not revealed. This works in reverse too, so if somebody attacks you, a public score is still calculated for your opponent. The only data saved when this occurs which relates to you is the attack "code" - this does not store your ID, but it is a unique identifier to the attack. This is never shared or available to anyone except myself and the developers when I have some strange results. Once I have confirmed this bug is resolved (unsure if TornPal or Torn bug at this stage), this code is no longer recorded and will be deleted from the DB.

If another person using FFScouter attacks you, then using their battle stat score, a "public" value is assigned to you. The public and private value do not interact and are separately considered. The private value is only ever used when calculating values for YOU to estimate target difficulty, others will never see or know of this value and have no way of finding it. This does lead to situations where using FFScouter, when you look at your own profile, the difficulty you see may not reflect your current stats. It is also not perfect.

In theory, your own FairFight score should always be 3.66 by the math, but as you can see, mine is a little off from a few days ago, I can only assume due to the person attacking me being significantly stronger and the difference is a rounding error in the math:

Screenshot

To extract battle stat estimates from the public FairFight Scouter score, the math is simply reverse and estimated. I provide "low" and "high" values to estimates. If you stats are perfectly distributed at 25% each, the "low" score should be close - stat whores tend to be towards the "high" estimate. Some people with extreme stat whoring may far exceed the estimate, but I think this is rare.

An API is available for this, which requires a limited or full key. You must first log into TornPal using this key before it can be used on the endpoint. This in essence returns the following information when this key and the target ID is requested, Omanpx shown below:

Screenshot

This matches that shown in the public profile earlier, as well as a "friendly" option which just makes it more readable for scripts to present, plus the estimate FF score as seen in the chain lists. "Message" is typically used for errors, such as no API key provided, or the API key is not on TornPal and you need to log in first.

Things TornPal Does Not Do

• Mug bots (more on this below)
• Request your live cash on hand (also below)
• Sell any data not publicly available

Cash on hand: Cash on hand is a separate selection in the API. This has never been used in TornPal, and never will as it isn't needed for functions. If this changes, it will be an opt-in system. However, the amount of cash you had on hand at midnight is recorded in the personalstats->networth category. As this data is requested no earlier than 1am daily for most people, and the value does not change for 24hrs, there will likely be at least 1 hour old. This value is also only available with a "limited" API key or above for yourself. This is not shared or used anywhere, nor will it be, but comes as part of the API response along with total networth.

Sell non-public data: Everything you have seen which is viewable by anyone but you is public. You do not need to be signed up for this to work. For example, Ched is not signed up to TornPal:

https://tornpal.com/profile/1

He does have battle stats missing since he can't be attacked, and his stats are fairly boring, but you get the point.

Mugbot Allegation

So, this accusation is a result of a conversation being misunderstood or passed on incorrectly, I do not know. However, for full disclosure, here is my message to IBF asking for clarification on a rule.

Tldr: TornPal does not have a mugbot, nor will TornPal have one in future, nor has it had one.

That is, if I, offering the same public API endpoint that Weav3r's script and many others use to browse bazaars and show only public data, were to offer a higher rate limit to subscribers (ie people who pay), and I become aware that they might be using (or know for sure) for a mug bot, does this put me in violation of Torn rules.

Message

The message itself makes clear that I am not building one - but I am concerned others may use my API to do so and what liabilities that may put on me as far as rules go.

Without going into the full back and forth, I have misread IBFs reply which said to take up issues of monetising the API with PJ/bogie, which I assumed to mean selling access to the public data. To clarify, Ched has previously informed me that selling Torn script services is fine as it is not RMT - however, my focus shifted at this point to "Can I sell the public data", and the potential uses of the mug bot faded from my concerns as IBF didn't mention that side (and therein lays my mistake, I focused on the word monetisation and not use in the reply).

To distinguish, the above question was a matter specific to TornPal. I may in future build one, but it will not be a part of TornPal or use TornPal's keys, name, data, databases etc. It would have to be entirely separate, perhaps not even run by me but I would just make the code and test it with my own keys. I have even made my own proof of concepts using my keys before, but not shared this yet.

However, I do have an issue, so let me address them:

[image: uploads.glasnost.dev]

The question of the mugbot above, I hope is addressed.

The last communication we had prior to TornPal relaunching, was to cease any activity that used keys in a way which users did not consent to me using in paid services. I run a poll in Discord, 94% knew after 118 votes, I believe the poll I sent you was taken a few hours before the end and was 96%, noting one of the unknowns was not registered on TornPal.

There was no reply from 16:37:58 05/05/25, until 14:52:46 08/05/25, despite me attempting to show there was information to show this. Evidently from your reply 3 days later you did not agree, and I was in limbo. After lots of opinions from people, I decided the best way to ensure this consent was to remove all keys which was suggested by a user, ramp up the notices to make your concern that I was profiting from it clear, and have everyone feed this back in again with the new notice so their API key would not be used until that time.

The above I hope has put into firm perspective how/where data is used, and I will of course answer any questions where I can.

Permission to collect all data is here, even though I do not collect all data, to cover future expansion of features:

What data is collected

I also did spell out what it was used for. This has now been improved as I mentioned with this post, expanding my data policy page and adding information to the login page that it is used in paid services.

How do you use it

This now does set out more detail above it and I took some questions from others to help identify any weaknesses too.

Let me be clear

I am very unhappy with this situation. I approached staff for a rule check, and it seems to have blown up after I decided the best idea presented to  me was remove all keys and try get permission gain instead of waiting indefinitely. I won't dive into specifics as I was asked not to discuss much detail publicly, but the admins and some staff know I try to help out with things behind the scenes and that myself and developers talk a lot - whether it is removing player reports from the API, talking about server performance, trying to diagnose and collect data on rare bugs etc. I am not somebody who has just walked in.

I find myself in a position no other developer is in. I will not be repeating the words of many other community developers, but they are well respected and frankly find this situation perplexing too.

In light of the "Do users know what they are signing up for" question. How many have public policies on what data is requested and how it is used before you sign up and the service has it? How many discord bots float around under the radar in a similar position? Not many have one, and not very clear either if they do exist.

The question of whether the developer profits from key, yes, should be disclosed and I have made improvements to that. But many of the questions asked of me today are one of how is the data used, is there informed consent and so forth. How can anyone expect to be giving that consent or know if the data is shared if there is no publicly available policy? Mine is on my login page with a summary and a more linked. I was asked what is considered public and private data - I use Torn's definition of public and private by the name of the API key level.

As for what it is used for, I try to employ a common sense approach as it would be frankly impossible to get new consent every single time as Torn provides no easy mechanism to do so - even posting in topics I ask people to subscribe to when signing up does not seem to pass the bar. So do we delete and start over, figure out a puzzle to keep segmenting keys off or just apply common sense?

If everyone on Torn can see, for example, a display case. Then if I already have broad permission from a user and want to expand from just bazaars to bazaars and a display case - this I struggle to understand how it would be an abuse if done on equivalent terms (ie, free and using public data). Same for paid services, if they are happy for me to use public data and offer a paid service based on the public data, as long as that is maintained and not too egregious, I don't see that as a problem, and if it stepped over a line then staff should notify that.

So my position with this is actually simple. I feel that these past 24 hours have been a slander campaign. Many, many people use TornPal, have no concerns or issues and the poll suggests people know how this works even when they didn't read the data policy by their own admission.

Baldr made a mistake of saying Limited keys were required - this was incorrect and a mistake I don't hold against him, he is in my books one of the most respected people on Torn and he was kind enough to acknowledge this mistake in a message earlier to me. Public keys are fine, and many features do not even require a key at all. However, it has grown into another grand old conspiracy theory at the cost of my reputation long before the truth can emerge, because I have somebody other than myself to take care of and a difficult job to do before I can come to a gaming community and explain how a vague statement has been miscommunicated, and have some corners act like I stole nuclear launch codes.

Consequently, will the admin team acknowledge a misunderstanding has occurred, and that the allegations made are a result of that misunderstanding? If not, where do I send the complaint. The usual conspiracy crowds love a bit of drama, and ironically are also the ones who previously said admins covered up for me/TornPal previously are now 100% behind the mugbot idea. Sounds like they aren't interested in the truth, just bringing people down whilst their own knowledge is zero, and gaslighting the staff to suit their own agendas.

Load image

reserved

Reserved

I don't know what TornPal is but I trust you with my API key more than bogie so good luck in your endeavours

reserved

reserved

reserved for Glas

reserved 

Preserved

Post for sale, Your message here 50m

felt cute, might delete later

reserved

[image: media1.tenor.com]

Edit: [Removed for fear of staff and committee members]

As someone with absolutely no knowledge on what half of that means, all I can say is

[image: en.meming.world]

But yeah this seems completely blown out of proportion here.

Oh and uh... reserved.