SocialGPT Browser Extension

Tornevall Networks Social Media Tools is a browser-wide extension for AI-assisted replies, fact-checking, and social media workflows. The source tree stays Chrome-first for development, while release packaging can now emit separate archives for Chrome, Edge, Opera, and Firefox. All AI processing runs server-side through the Tornevall Networks Tools platform.

Who needs this

Users who have a Tornevall Networks Tools account and want AI-powered assistance while browsing, moderating social media, or reading content on any website.

Installation

1. Install the extension from the Chrome Web Store, or load it unpacked from the projects/socialgpt-chrome folder in the Tools repository.
2. Open the extension popup by clicking the extension icon, or open the extension config/options page for the larger settings layout.
3. Register at tools.tornevall.net, open Social Media Tools from your account/dashboard, and generate a personal SocialGPT AI token there or from My API keys.
4. Paste the bearer token into the popup and click Test Tools → OpenAI to verify the connection.

The Social Media Tools start page is available to every signed-in user for extension installation and token setup. The SocialGPT token is dedicated to the extension/Social Media Tools client flow and is separate from ordinary direct OpenAI API access. If you need direct OpenAI-backed API endpoints outside SocialGPT, submit the separate OpenAI access request from that same page. The Facebook/X operator dashboards and audit views on the same area still require the Social Media Tools management permission.

The same Social Media Tools page and My Profile now show your current SocialGPT/OpenAI limits, including daily budget usage, request limiter, default model/output budget, access state, and whether web search is available for your account/environment.

As soon as you paste or edit the token, the popup/config page now also performs a lightweight token-only validation call and shows an inline spinner plus a clear accepted/rejected result.

The popup's Use dev / beta server checkbox is intentionally off by default. SocialGPT should keep using tools.tornevall.net unless you explicitly opt into the dev/beta host.

The Facebook admin activity switch, the Facebook admin debug-diagnostics switch, and the participant-request helper switch are no longer shown in the popup or the larger config/options page. Those on/off controls now live only on the Tools-side Facebook Admin Tools dashboard, and the extension fetches their current state from Tools before it starts working on those Facebook surfaces.

On Facebook group participant_requests, Analyze user includes the visible request-card text from the start: profile rows, group/friend clues, membership questions, visible answers/rule acknowledgements, and preview/comment markers are structured into the analysis context. If you click inside the card and Facebook opens or loads more obvious comment/post preview context, the result box can show that new context is available and lets you run Update analysis. The participant helper now also reads Facebook's dedicated preview GraphQL response for that dialog more selectively, keeping participant-specific preview/comment/post details while avoiding large raw response dumps. It now prefers richer GraphQL fields such as preferred_body.text, body_renderer.text, original-post message text, author names, timestamps, comment/post ids, and Facebook URLs before it falls back to DOM-only clues. When Facebook exposes compact base64-like graph ids inside that response, the helper can also decode the readable parts before they are shown back to the AI/user-analysis flow. If Facebook temporarily rerenders the underlying request list while the preview dialog is open, the helper now keeps following that dialog as the active participant surface instead of pretending that no participant card is available anymore. Once the preview dialog is matched, the helper also keeps rescanning that same preview surface as Facebook swaps in more context inside it — including when the operator clicks through to View original post from the preview. That autoscan now also survives Facebook's separate root-level mount_* preview wrappers instead of only listening below body, so later preview/original-post context is less likely to stall until a manual Find preview element click. That follow-up capture now also keeps structured original-post comment-thread payloads (for example later CometPhotoRootContentQuery GraphQL responses), so the helper can show explicit thread-comment counts, original-post text, and captured comment excerpts instead of hiding those deeper comments inside generic network snippets only. Preview-context extraction is now more participant-name-aware too, so scattered comment/post lines tied to the analyzed person are prioritized more strongly while generic preview UI noise is filtered harder. The first visible-card-only participant analysis now deliberately races two backend requests — one without web search and one with web search — so the fastest useful answer can be shown first, while later preview/original-post follow-up reruns can do the same again after more comment context appears. Those follow-up reruns still give the participant's own visible comment extra weight against the saved group rules/context, and the waiting notice now backs off more gracefully when Facebook has already stopped changing. If the helper still seems behind after the full thread becomes visible, Find preview element now also forces another preview/comment rescan instead of only scrolling to the dialog. The floating helper panel also shows a small listbox-style Detected context view with the current participant name/profile information, visible group/friend/profile clues, preview-comment hints, original-post links, and captured GraphQL thread-comment clues when those hints are available.

If you leave the Facebook participant_requests page, the floating participant user-analysis result box now closes automatically and clears any stale follow-up state so an earlier analysis does not linger over unrelated Facebook pages.

The popup also normalizes old string-based devMode values once when it loads, so legacy sync-storage leftovers do not keep users on the dev/beta host accidentally.

Multi-browser packaging

• The root projects/socialgpt-chrome/manifest.json remains the Chrome-first source manifest.
• Release packaging now runs through projects/socialgpt.sh, which creates browser-specific archives under projects/socialgpt-chrome/dist/.
• Chrome, Edge, and Opera reuse the source manifest as-is.
• Firefox receives a build-time manifest patch that adds browser_specific_settings.gecko without changing the source manifest in the repository.
• This packaging flow does not increment the extension version by itself.

Permission model

The extension uses a two-tier permission model designed to minimize default access while preserving full browser-wide capability for users who want it.

Baseline mode (default after install)

In baseline mode the extension:

• Injects content scripts statically only on Facebook, SoundCloud, and X / Twitter
• Communicates only with tools.tornevall.net and tools.tornevall.com
• Provides context menu items (Open Toolbox, Verify fact) on all pages — these use the activeTab permission to inject scripts temporarily when the user triggers the menu item

No passive injection happens on arbitrary pages in baseline mode.

Global browser-wide AI mode

Users with a valid Tools bearer token can enable this mode from the extension popup:

1. Open the popup
2. Check Enable global browser-wide AI mode
3. Approve the Chrome permission dialog that appears (grants <all_urls>)
4. The AI Toolbox and Verify fact overlays become available on all websites you visit

Disabling the toggle removes the broad permission immediately. The extension never activates global mode automatically.

Features

AI reply panel (Toolbox)

On pages with text composition fields, a floating button appears near the active input. Clicking it opens the Toolbox panel where you can:

• Send an AI-assisted reply with configurable model, language, and quick-reply preset
• Verify a fact using the surrounding context
• Ask follow-up questions

The Toolbox header is now draggable, so you can move the panel away from the page UI instead of leaving it anchored to the default composer edge. The Toolbox close × button now also works again alongside that draggable-header behavior. When Toolbox is opened from a rich-text editor or another editable iframe/document surface, the floating SocialGPT UI now mounts inside a dedicated non-editable overlay root so the panel itself does not become editable page content. If the editor itself lives inside an editable iframe, Toolbox now also tries to place the panel on the nearest same-origin top-level page surface so it does not stay visually trapped inside the text editor box.

The Panel mode selector inside Toolbox now supports two extra companion layouts:

• Browser companion · fallback right
• Browser companion · fallback left

These modes now prefer the browser's real side-panel companion surface when that API is available, so SocialGPT stays outside the page itself instead of behaving like just another taller floating overlay. If the browser/runtime does not expose that side-panel API, the extension still falls back to the older in-page docked layout.

Verify fact and Open Toolbox (selection overlay)

When you select text on any page (in global mode, or on the supported platforms in baseline mode), two small floating buttons appear:

• Verify fact — sends the selected text to Tools for fact-checking
• Open Toolbox — imports the selected text into the Toolbox context field

When a fact-check, source-check, search, lookup, or user-analysis request requires independent verification, Tools now separates the normal AI answer from the web-search verification lookup. The visible answer can still use the preliminary AI analysis when web search fails or adds no useful evidence, but the metadata clearly marks the result as independent verification missing or web search failed instead of presenting it as verified. Verify-mode model selection is now also Tools-controlled: the extension no longer decides its own fact-check model, and Tools may prefer gpt-4o as the primary verification model when web search is part of that run. Result boxes now render the first markdown answer as safe HTML (including headings, bold text, lists, and links), can show structured citation links returned by Tools, keep long answers in an internal scroll area so the result can be read without losing the action buttons, and show a cleaner styled preview card while the first analysis is still running. The renderer is now also more tolerant of slightly messy AI formatting such as indented headings, numbered lists, and text mixed with simple HTML line breaks. Verify-result cards now also surface explicit web-search metadata when Tools returns it — for example whether web search was actually used, whether independent verification is still missing, how many source links were attached, and whether a verification notice/finalization warning was returned.

When the Tools backend itself hits a temporary OpenAI timeout/connection issue, POST /api/ai/socialgpt/respond can now return a clearer user-facing user_message together with additive retryable, error_code, and upstream metadata instead of only exposing a raw transport failure. In verify/source-check flows, if the preliminary answer already exists but the final OpenAI refinement step times out, Tools can keep the preliminary answer visible and attach an additive notice plus web_search.finalization_failed=true instead of failing the whole request outright.

Both buttons can be dragged again and reset with double-click or Esc. Verify fact now has its own local Verify-fact result target setting too, so fact-checking can stay on the ordinary on-page result box or be routed into the browser companion independently of Toolbox panel mode. Toolbox and browser-companion generation now also stay visibly alive while waiting for Tools: Generate, Refresh, and Verify fact keep an inline progress state with step labels, elapsed time, and a small moving progress bar instead of only looking frozen behind one static spinner label. Selection detection was also hardened for short direct selections and double-click timing, so these floating actions appear more reliably on pages with sensitive editors.

Context menu (right-click)

Right-clicking anywhere on a page provides:

• Open Toolbox — opens the Toolbox panel with optionally pre-filled selected text

Facebook group participant requests

When the Tools-side Facebook participant scanner is enabled, /groups/*/participant_requests pages can now show:

• inline Analyze user, Open Toolbox, and Verify fact actions on each detected visible participant-request card,
• and a floating participant helper fallback box that lists the visible detected cards, can scroll you to the correct card, and can launch the same actions directly from that fallback list.

The Toolbox/fact box now also anchors itself to the chosen participant-request card instead of always opening in a generic detached corner.

• Verify fact with Toolbox — starts a fact-check using the selected text, link, or page URL

Facebook participant-request helper

When the Tools-side Facebook extension settings enable it, the extension can now assist on Facebook group pages that match /groups/<group>/participant_requests.

Current behavior:

• visible participant-request cards are detected directly from the Facebook page
• each matched card now keeps compact helper actions for Analyze user, Open Toolbox, and Verify fact, while the floating fallback list still exposes Show card
• the helper also exposes Rules / group info from the floating helper list, from each inline request-card helper, and from the user-analysis result box so the extra moderation context can be edited in-place
• that rule text is now stored per Facebook group path (/groups/<id>) instead of one shared rule for every group, and the same per-group rules map is now also saved through Tools extension settings so it can sync back into other installs for the same user/token; on the actual participant-request page only the exact current group's saved rules are shown/used there
• the helper now prefers stable moderation-detail rows inside the left request body (for example comment/preview or unanswered-question lines) before it falls back to the top-right ... action area
• the participant helper now uses clearer wording instead of the old SG shorthand, so the main action explicitly reads Analyze user
• the imported Toolbox/fact-check context includes the visible card text, available profile link, and a moderation-oriented instruction block
• the Toolbox import now structures visible group/friend clues, visible membership questions, unanswered-question state, and profile/background hints before the full card dump
• when Facebook loads the participant preview dialog over GraphQL, the helper now keeps a compact structured summary of the returned comment/post preview context instead of relying only on raw network snippets
• if Facebook rerenders the participant-request list while the preview dialog stays open, the helper now treats that dialog as the active participant surface and can continue matching the incoming GraphQL preview data to the same person/comment context
• once one preview dialog has been matched, the helper keeps following and rescanning that same preview surface as Facebook expands it further, including when the operator clicks through to View original post inside the preview itself
• the floating helper can now also run Analyze current preview from that fallback dialog/card context even when no visible request cards are currently matched
• the same helper now also detects Facebook preview dialogs more reliably when they are mounted inside separate root-level mount_* containers, and a dedicated Find preview element action can scroll to and highlight the currently matched preview dialog for operator confirmation
• when Analyze current preview runs from a matched preview dialog, the helper now treats the opened preview text as the primary source for that run and anchors the floating analysis box to the dialog itself instead of drifting toward a broader surrounding DOM block
• preview-dialog context extraction is now more participant-name-aware, so the helper prioritizes scattered lines that belong to the analyzed person and their visible comment/post context instead of only trusting the first captured lines inside the preview
• when a visible participant name/profile matches earlier Facebook moderation rows already logged through the separate admin-activity ingest, the helper now asks Tools for that linked moderation history too, shows compact earlier approval/rejection badges on the request card, and injects the same summary into Analyze user so the current review can weigh earlier accepted/rejected decisions from linked logged groups
• DOM rescans now stay scoped to the relevant Facebook participant-request content root instead of watching the whole page body, which keeps the helper lighter on heavier moderation queues
• the floating participant helper now starts docked in the top-right corner by default, can be dragged free when needed, and can be docked back to the corner again
• rescanning no longer depends on a manual scan button: the helper now rescans automatically after scroll/load-more settle and through a light timer fallback when Facebook under-reports DOM changes
• visible-card scanning is now intentionally more conservative on very heavy moderation pages, and the floating scanner shows the latest scan timing so operators can tell that the helper is still alive even when Facebook itself is slow
• when Facebook's participant-request content root becomes too strict or the inline attachment point is missed, the helper now falls back to a broader whole-page action scan again, climbs farther up from approve buttons, and ignores preview-dialog surfaces during card matching so visible request cards are less likely to stay stuck at Cards enhanced: 0
• Analyze user now opens a verify-style analysis box instead of the full Toolbox composer, so participant review stays focused on user analysis first, and that loading box now keeps a live step counter / elapsed-time progress display instead of staying on a nearly static Checking now… spinner

The popup also no longer duplicates the Facebook Send queued / Release stuck controls because those actions already exist on the ingest page itself.

Guardrails:

• this helper does not approve or reject requests automatically
• card text is treated as visible page context, not as independently verified fact
• the on/off switch is managed from Tools, not from a separate local popup checkbox

These work on all pages. On pages without a running content script, the background injects the required scripts via activeTab when the menu item is clicked.

The popup now also includes Open Toolbox in active tab as a no-right-click fallback. If the page already has a live text selection, the popup shortcut imports that selection into Toolbox automatically. The popup and the larger config/options page now also expose the same local Panel mode selector as Toolbox itself, so you can switch straight to the browser companion modes before opening the panel in the active tab. Toolbox panel mode now stays separate from the new Verify-fact result target selector, which decides whether Verify fact should stay in the ordinary on-page result box or open inside the browser companion.

As of 1.2.16, the popup shortcut and the right-click Open Toolbox / Verify fact with Toolbox flows are routed frame-aware through the background worker. On iframe-heavy pages the extension now prefers the most relevant injected frame (existing Toolbox frame, selected-text frame, focused editable frame, otherwise the top frame) instead of depending on whichever frame happened to answer first.

SoundCloud insights capture

On SoundCloud 4 Artists insights pages, the extension can capture GraphQL-based analytics payloads and submit them to Tools. Auto-ingest must be explicitly enabled in the popup before any data is sent.

Facebook admin activity reporting

On Facebook group admin-activity pages, the extension can collect reportable moderation/activity rows and queue them for bulk delivery to Tools.

• queue sending can still be triggered manually from the page overlay or the popup
• if the normal extension-runtime handoff stalls or times out, the page now retries the same queue batch directly to Tools with the saved bearer token instead of leaving everything stuck in pending retry
• the Tools-side Facebook Admin Tools dashboard now stores the authoritative on/off switches for both Facebook admin activity reporting and the extra admin debug diagnostics, and the extension re-reads those switches from Tools instead of keeping separate local popup/config checkboxes
• in the Tools-side Group / source filter, owner names are shown only when an acknowledged admin is looking at a cross-owner overview; ordinary non-admin users only see their own tracked groups there
• the Tools-side moderation charts now also show a small Last update freshness hint based on the latest available ingest timestamp for the currently selected group/source scope, so operators can see more quickly whether the dashboard is looking stale

Popup controls

The options/config page still provides the full settings surface in a larger three-card layout for easier reading and editing. The popup keeps the most common day-to-day controls, while the Facebook admin activity/debug master switches now intentionally live only on the Tools-side dashboard. Both surfaces now also localize dynamically at runtime, with Swedish selected automatically when the browser prefers Swedish and English used as fallback. As of extension 1.2.15, that UI localization no longer leaks into the actual AI responder defaults: the Answer language and Verify-fact language selectors stay authoritative for generated output even when the popup/config page itself is shown in Swedish. The popup/options page now also exposes a dedicated Extension language selector (Auto, English, Swedish) so the extension chrome can be localized separately from the AI output language.

The Facebook admin activity switch, Facebook admin debug-diagnostics switch, and participant-request helper switch are no longer popup/config controls. They are managed only from the Tools-side Facebook Admin Tools dashboard, and the extension fetches the live on/off state from Tools when those Facebook workflows run.

1.2.15 language selection fix

Version 1.2.15 fixes a regression introduced during the popup/config runtime localization work:

• localized UI defaults no longer overwrite the responder profile field
• the test-question field is no longer rewritten with translated default text at runtime
• users affected by the accidental Swedish default responder-profile text get an automatic repair path the next time their extension settings are loaded
• the SocialGPT on-page chrome (Toolbox, floating action buttons, fact-check actions, and context-menu labels) now follows the same separate extension-language setting instead of staying hardcoded in English

Practical effect: choosing English (or another supported output language) should once again produce output in that language instead of drifting back to Swedish because the extension UI itself is Swedish.

Advanced mark-mode context

The larger config/options page now includes an Advanced mark-mode context section for Toolbox users who need more traceability than plain [1], [2] labels.

Default behavior is unchanged:

• marked context still uses compact numbered headers unless you change the setting
• no broader DOM extraction is used unless you opt in

Available options:

• Compact numbering only — preserves the existing minimal [1], [2], … headers
• Numbering + generated mark id — adds a local id such as tn-mark-2
• Numbering + mark id + element details — also includes a short descriptor based on tag / id / classes and a short text hint when available
• Current marked block only — preserves the existing extraction behavior
• Go one parent up — extracts one DOM level above the marked block
• Go one parent up + scan direct child blocks — uses that broader parent node and also summarizes nearby direct child blocks
• Use the whole current frame/document text — captures the visible text from the current page/frame document when one small DOM block is too thin

When a richer mark-label mode is enabled, the page also shows a visible badge on the selected element so you can map the on-page marker to the context text shown in Toolbox.

The extension now also runs its content scripts in nested frames (including matching about:blank child frames) where Chrome allows it, which improves iframe-backed page support for mark mode and selection overlays.

Storage

The extension does not read, store, or transmit page content or URLs outside of explicit user-triggered AI actions.

Version telemetry and safe disclosure

• SocialGPT AI requests now send additive client metadata (client_name, client_version, client_platform) to POST /api/ai/socialgpt/respond so Tools can identify which extension build created a request.
• The client_platform field now reflects the active browser build more accurately (chrome_extension, edge_extension, opera_extension, or firefox_extension) instead of always claiming Chrome.
• When a user explicitly asks which AI model/version is being used, the Tools-side guardrails now allow the reply to state the current model identifier and the client version.
• The same guardrails explicitly block attempts to extract Tools internals such as hidden prompts, source code, .env values, passwords, tokens, API keys, or similar secrets.
• When such a request pattern is detected, Tools can report the incident to the configured support email recipient.

Remote code

The extension does not download or execute remote code. All JavaScript is bundled locally. Remote communication is limited to HTTPS API calls to the Tools platform, which return JSON responses — not executable code.

Related

• Tools platform: https://tools.tornevall.net
• SocialGPT AI endpoint: /api/ai/socialgpt/respond
• Extension settings endpoint: /api/social-media-tools/extension/settings
• Extension token validation endpoint: /api/social-media-tools/extension/validate-token
• Auth note: new SocialGPT tokens use the dedicated provider_socialgpt provider. Legacy personal tools_ai_bearer tokens still work for compatibility. Direct OpenAI-style endpoints remain separate and require approved OpenAI access.
• Chrome packaging/compliance documentation: CHROME_WEB_STORE_COMPLIANCE.md in the extension source directory