SocialGPT 1.2.19 makes fact verifications easier to review, easier to share, and much less frustrating when something is slow or behaving strangely.

This update mainly focuses on three things:

1. better control over Verify fact
2. saved verifications you can reopen later
3. clearer visibility when you want to understand what is happening in the background

What’s new?

Fact verifications are now saved automatically

When a verification succeeds, it is now saved as a real fact card in your Tools account. That means you no longer have to run the same check again just because you want to read the result later.

This makes it easier to:

• go back to an earlier verification
• review the sources at your own pace
• compare multiple verifications over time
• share a saved result afterwards

Share links for saved verifications

Saved fact cards can now get a public share link. In practice, this means you can run a verification once, save the result, and then open or share that same version again without having to run it again.

This is especially useful when you want to:

• show a finished verification result to someone else
• save a reference to an important check
• reuse the same result in follow-ups or documentation

Fact cards now have a better reading format

Saved verification cards are now shown in a more editorial and readable format instead of feeling like a raw text dump.

Markdown is also supported better, which makes headings, lists, links, and simple structure much clearer when a card is reopened or shared publicly.

In short: results now feel more like finished articles and less like internal debug text.

New discreet debug panel in verification view

If you want to understand why a verification is taking time or acting strangely, there is now a small dbg opener directly inside the verification box.

It shows things like:

• which phase the verification is in
• how long different parts take
• request token and timeout
• transport details between the extension and Tools
• a compact preview of the response or error

This is mainly for troubleshooting and follow-up, without making the normal verification UI noisy for everyone else.

Verify fact timeout behaves better

A slow or stuck verification should no longer keep counting forever without actually ending.

In 1.2.19, the verification flow now uses the same timeout logic as the other AI calls in the toolbox. That makes stuck verifications easier to catch and makes it clearer when a response is simply not coming back.

The debug panel is easier to use

The new debug panel also received important usability fixes:

• it can be opened without getting caught by the drag behavior of the box
• it has its own scroll when the information gets long
• the content is easier to read and copy

For people using Facebook admin and review workflows

This release also continues improving visibility in Facebook-related workflows.

Among other things, the admin overlay is clearer with:

• visible queue and dedupe status directly in the panel
• better presentation of the latest batch result
• clearer marking when scrolling has reached content that is already known or already sent

That makes it easier to see what is actually happening without having to guess.

Short summary

SocialGPT 1.2.19 makes Verify fact more practical in day-to-day use:

• verifications can be saved and reopened
• saved results can be shared
• fact cards are easier to read
• timeout behavior is better
• there is now a built-in debug surface for people who need more insight

This release is mainly about improving the workflow after the verification itself — not just the answer you get, but how easy it is to understand, save, reuse, and troubleshoot it.

An internal incident recently affected parts of the platform and interrupted some normal account and data flows. This was not an external hack, but a recovery situation tied to internal automation and backup handling. A large part of the service is already back online, but some older data still has to be rebuilt carefully before everything can be treated as fully restored again.

For some users, that may mean reconnecting credentials, resetting passwords, or recreating specific tokens instead of expecting every older connection to return automatically. The recovery work is continuing, and the goal is to restore access safely without reintroducing broken or uncertain data. At the same time, development has not stopped completely around SocialGPT, and new features are still planned once the current stabilization work is in a better place.

We have started laying the foundation for Trustpilot for Social Media.

The idea is simple: people should get better help understanding whether a website, link, post, or source seems trustworthy, questionable, or worth checking more carefully.

Today, we often meet information without any useful context. A link appears in a feed. A post gets shared. A website looks serious enough. A claim is repeated often enough. And suddenly, people are expected to decide for themselves whether it deserves trust.

That is not always easy.

A trust layer for the web

Trustpilot for Social Media is meant to become a kind of reputation layer for the web.

Not a system that decides truth for everyone. Not a censorship tool. Not an automatic judge.

More like a warning light.

If a site has a long history of misleading content, scams, conspiracy material, or other serious problems, the user should be able to see that before trusting it. If a source has a stronger reputation, that should also be visible. If nothing is known, the system should simply say that.

The browser could show a small label or icon when visiting a website. The user could click it to read more, report a page, or see whether others have flagged the same source.

That kind of context could help people slow down before sharing, reacting, or believing something too quickly.

But reputation systems are risky

A system like this also comes with problems.

A report is not the same thing as a fact. People can misunderstand things. They can also abuse reporting systems on purpose. Competitors, political groups, trolls, and angry users could all try to damage someone else’s reputation.

That means reports must be handled carefully.

A single report should not become a public warning. Community signals should not automatically become truth. Admin review, correction options, and transparency need to be built in from the start.

The system should help people think, not tell them what to think.

GDPR cannot be an afterthought

There is also a privacy side to this.

Reporting a website is one thing. Reporting a person, a social media profile, a comment, or behavior connected to an account is something else.

That can become personal data very quickly.

Because of that, GDPR has to be part of the design from the beginning. The system should collect as little data as possible, avoid storing unnecessary personal details, and clearly separate website reputation from anything related to individuals.

Users must understand what happens when they report something. Is the report private? Can it become part of community data? Will an admin review it? Could AI be used to help analyze it? Can it be corrected or removed later?

Those answers need to be clear.

A reputation system without a correction process is dangerous. Websites can improve. Reports can be wrong. Context can change. People must be able to challenge, correct, or remove bad information where appropriate.

AI can help, but should not decide

AI can be useful in a project like this. It can help summarize reports, compare sources, detect patterns, and support fact-checking.

But AI should not become the final judge.

If AI is used, it should be clearly marked as support. It should also be optional, because every AI-assisted check costs money and may involve sensitive context.

The default should be cautious and privacy-friendly.

Starting small

The first version should not try to classify the entire internet.

A better start is to support moderation and basic source reputation. For example, helping admins understand whether a user, comment, post, or link needs a closer look before approval.

From there, the system can grow into browser warnings, community reports, public reputation pages, and deeper fact-checking tools.

So, do we need it?

Probably.

The web has a trust problem. People are constantly asked to judge sources, claims, links, and posts without enough context.

A careful reputation layer could help.

But it has to be built with limits. It needs transparency, privacy, GDPR-aware design, human review, and a way to fix mistakes.

The goal is not to control what people read.

The goal is to help people understand what they are looking at before they trust it.

We are continuing to develop Tornevall Networks Toolbox for Social Medias with a clear focus on fact-checking.

The idea is simple: to gather information from established fact-checking organizations such as Snopes, Källkritikbyrån, Motargument and others, and use that to create a clearer picture of what is actually accurate in what we see online.

Rather than pointing out individual posts, the goal is to improve the overall understanding of how information spreads. By following different sources over time, it becomes easier to see how topics change, grow, or shift direction.

This is especially relevant during election periods, when the amount of information increases and it becomes harder to separate facts from misleading claims.

By combining multiple sources, we want to make it easier to see the bigger picture without relying on any single actor.

This is still a work in progress, but the ambition is straightforward: to make it easier to understand the flow of information online.

If you have suggestions for fact-checkers we should include, feel free to reach out.

It has been a while since there was any real movement across the wider Tornevall Networks ecosystem.

That was not because everything had stopped. Most of it kept running just fine. But like many privately maintained projects, a lot of ideas ended up sitting in the background for far too long simply because life, time, and energy had to go elsewhere.

That has started to change.

Over the last few weeks, several parts of the platform have begun moving again – not just in maintenance terms, but in actual development. Some older services are being cleaned up, some tools are being rebuilt properly, and a few things that had been sitting half-finished for too long are finally getting the attention they should have had earlier.

One of the biggest shifts is happening around tools.tornevall.net, where a larger rebuild has made it possible to modernize parts of the ecosystem that had become too slow, too fragmented, or simply too outdated to keep patching forever. DNS-related tooling is being refreshed, documentation is being brought closer to reality, and a number of internal and public-facing interfaces are becoming more usable than before.

This also connects with changes already visible on the site. SocialGPT marked one kind of step forward. The ongoing DNSBL removal rebuild marks another. Older infrastructure is not being thrown away for the sake of it, but where something needs a cleaner structure, it is now being rebuilt with that in mind.

So while this is not a grand relaunch of everything at once, it is a very real shift in direction.

The platform is active again. Development is active again. And several long-running ideas are finally starting to look like real, usable systems instead of permanent work in progress.

Current areas of focus include

• Rebuilding and modernizing tools.tornevall.net
• Refreshing DNS-related tooling and removal workflows
• Cleaning up older services and legacy structure
• Improving documentation so it better reflects reality
• Making internal and public-facing interfaces more usable
• Bringing long-running ideas closer to fully usable systems
• And much much more not even written down yet