JenkinWoo/sheeridVerify

Source
GitHub
First trending
Category
Workflow
GitHub stars
741
Main language
JavaScript

This page introduces an external open-source repository. It is not an HDATF product.

What it does

sheeridVerify is a Node.js workbench for learning and authorized testing of SheerID verification workflows. Its intended users are educators, researchers, and testers with permission to handle the submitted information. A job takes a verification link, a name, a birth date, and configured school and document sources, then produces queue progress, logs, and a result reflecting the remote state. It queries the current verification step before choosing browser form interaction or document upload. Documents are read as original PNG, JPEG, or PDF bytes rather than generated or altered, and interactive human challenges remain with the user. The web workbench controls concurrency and allows cancellation, resumption, and deletion, but its queue and history are held in memory and disappear on service restart. When a submission response is uncertain, the workflow queries the remote state instead of immediately repeating the write. It requires Node.js 22.15 or newer, Camoufox for the browser branch, and access to SheerID and any configured document or proxy service. Real personal information can reach those services, and deleting a local task does not revoke a remote submission or erase disk logs. Constructing an email string does not prove ownership or student status, and the project disclaims affiliation with SheerID and any guarantee of successful verification.

License

ISC Custom or non-standard license. Read the license file before any reuse.

More in this category

  • render-oss/render-mcp-server
    Render MCP Server is Render's official bridge between an AI application and resources hosted on Render. It uses MCP, a protocol through which an AI application discovers tools and passes structured parameters to them. Inputs include workspace and resource identifiers, log filters, service settings or SQL, and outputs include resource details, operational records and query results. Tools cover service and database creation, deployment history and triggering, logs, metrics and environment-variable replacement. The Postgres query tool wraps queries in a read-only transaction, but other tools can change infrastructure or initiate deployments. Clients can connect to the hosted endpoint or run a local executable or container with appropriate credentials. Database queries use the external database connection and remain subject to its IP allowlist. This is not complete Render administration, and sensitive information can still reach the AI context even though the server attempts to reduce exposure.
  • render-oss/cli
    Render CLI is Render's official command-line client for developers and operators managing Render resources. It accepts commands, resource identifiers and options, and returns interactive menus or structured JSON, YAML and text output. It supports service and datastore inspection, deployments, restarts, one-off jobs and live log filtering. It also provides SSH and Postgres sessions and validation of Blueprint configuration files. Non-interactive operation is intended for scripts and CI/CD, with deployment waiting and failure exit status available for automation. It needs a local executable, Render access and authentication, using browser-authorized CLI tokens or an API key for automated environments. Commands operate on the active workspace, and write operations can affect live resources rather than merely generate suggestions. Current documentation states that usage telemetry is enabled by default, and sensitive credentials, confirmation policy and command-specific external dependencies still require operational care.
  • KKKKhazix/agent-autoloop
    This automation layer lets terminal agents react to events and ask a person only when a decision is needed. It calls already installed and authenticated executors such as Claude Code and Codex rather than supplying its own model. Schedules, GitHub events and external HTTP events are assigned to agents and workspaces by rules. Final replies and structured receipts become completion records, question cards, notices or deferred follow-ups. While awaiting an answer, the agent process exits and can resume the existing session after a response. It requires macOS or Linux, Node 24, Git, curl and an authenticated agent; the README currently states Windows is unsupported. Event sources, notification channels, agents and delivery pipelines are plugins requiring configuration. Some channels and business recipes have only simulated validation, and the generic command adapter does not enforce every executor's permissions. Model usage belongs to the connected account, while hostile input and file access under the same system account require separate controls.
  • thtbee/nectarlink
    NectarLink is a device companion for people who move between an Android phone and a Windows PC. With permission, phone notifications, messages, clipboard content, files, photos and screen content become available on the paired PC, and selected controls work in the other direction. A shared Rust core handles device identity and pairing, while the desktop and Android applications provide their respective interfaces. Devices normally communicate directly over the local network or USB using encrypted connections, and mobile-data relay is optional. Setup involves installing both applications, confirming pairing and enabling only the features the user wants; some advanced Android features require separately authorized debugging access. An optional local HTTP and JSON automation API supports actions such as sending files, notifications and camera requests, requires a Bearer token and is disabled by default. The documented v0.1.4 packages cover Windows x64 and Android, while Linux and Windows ARM64 packages are described as forthcoming and macOS remains a preview. This is not a cloud collaboration service, third-party chat history is limited by notification access, and call audio still stays on the phone even when calls are controlled from the PC.
  • emanuele-em/kanzo
    Kanzo is a self-hosted task board that lets people and coding agents work on the same projects. People enter tasks, descriptions, comments and images through a browser, while agents use MCP, a protocol connecting AI tools, or the command line. The Rust program provides a REST-style JSON API and MCP over standard input and output or HTTP, stores tasks in SQLite and images as local files, and updates the browser through polling. A default launch opens localhost:4242, while sharing and joined modes provide a shared host board and relay remote requests. Tasks support todo, doing, review and done with optional backlog, tags, ordering, comments and timestamps, but the inspected schema does not provide assignees, dependencies or an audit history. The next_task operation selects a non-Human todo task and changes it to doing inside a write transaction, preventing competing selections by design without granting exclusive ownership. Human tasks are omitted from agent listing and automatic selection, but update and delete operations do not enforce Human protection when an agent knows the identifier. There is no separate read-only token, and anyone who can reach the shared port can change the board, so choosing local or shared operation, the data directory and network restrictions is a prerequisite. Distribution targets macOS, Linux and Windows under AGPL-3.0-only, while advertised size, memory use, start time and token savings remain upstream measurements rather than independently verified results.

Only repositories in the ranked Trendshift lists are included, and the lists are used only to find candidates. We do not copy their ranks. Descriptions, licenses and star counts come from each GitHub repository. The notes are our own reading. We have not tested these projects, and a place on a trending list does not prove quality.

View on GitHub (opens in a new tab)