Most personal websites still assume one kind of visitor: a human with a browser. That assumption no longer feels complete.

My portfolio at gabrimatic.info is a Flutter web app because I wanted the website to feel designed, not assembled. Motion, composition, spacing, atmosphere, all of that matters to me. But lately a second visitor has become just as important: the AI agent acting on behalf of a person.

That changes the problem.

An agent does not benefit from a polished hero section if it cannot discover the right endpoint. It does not care about careful animation if the content is trapped behind a canvas. It needs structure, protocol support, machine-readable policy, and most of all, trust.

A big part of my current work sits around privacy-first digital identity and open trust standards: verifiable credentials, DIDComm v2.1, OID4VCI, SD-JWT, and EUDI. I did not expose those identity protocols directly on the portfolio, because that would be the wrong abstraction. But they shaped how I designed the public agent surface. I wanted explicit metadata instead of hidden assumptions, verifiable keys instead of opaque trust, standard discovery instead of folklore, and scoped machine-readable access instead of scraping.

The question I wanted the site to answer was simple: if an agent lands here, how does it discover what exists, know what is authoritative, understand what is allowed, and verify what it receives?

The result is now public. If you open /agents.html, you can inspect the whole surface from the outside.

Start with the obvious: structured retrieval

The first layer is simple and useful. I exposed three public JSON endpoints:

• /api/profile
• /api/journey
• /api/repos

These endpoints answer the obvious questions directly: who I am, where I am based, what I work on now, what my professional timeline looks like, and what public repositories are live right now.

The repositories endpoint is especially useful because it is not a static export. It proxies live GitHub data and supports query parameters such as per_page and sort. That sounds small, but it changes the feel of the interface. An agent can ask a narrow question instead of downloading everything and improvising.

For many clients, that layer is already enough. But a portfolio is not just profile data. It is also text, and text deserves a cleaner path than scraping.

Then give the content a canonical machine-readable form

The site is a Flutter app, which means the human-facing content is rendered as an application rather than a simple document. That is fine for people. It is not the best path for agents.

So every public route also supports Markdown negotiation. If the request includes:

Accept: text/markdown

the route returns Markdown instead of HTML. There are also direct Markdown URLs for all five public pages:

• /index.md
• /journey.md
• /interests.md
• /opensource.md
• /definition.md

This keeps both audiences happy. The visual app stays visual. The agent gets a canonical text representation of the same content. No scraping, no guessing, no mismatch between the designed layer and the retrievable layer.

MCP turns the site into a tool surface

Once the data and content layers were in place, I exposed a public Model Context Protocol server at:

POST https://www.gabrimatic.info/api/mcp

It is a stateless MCP endpoint over Streamable HTTP and JSON-RPC 2.0. The public tools are:

• get_profile
• get_journey
• get_repos
• get_page_markdown

This is where the portfolio stops being only something to read and becomes something to query intentionally. An MCP client does not need to understand my frontend at all. It can call a stable tool contract and get structured output back.

The endpoint is also discoverable through a public MCP server card at /.well-known/mcp/server-card.json, which documents the endpoint, the transport, the tools, the resources, and the auth metadata.

The part I especially like is the posture: anonymous read access is allowed, but the trust model is still explicit. That is a good default for a public portfolio. Easy retrieval, not vague retrieval.

A2A gives the portfolio an agent identity, not just endpoints

I also exposed a public Google A2A endpoint at:

POST https://www.gabrimatic.info/api/a2a

with its public agent card at /.well-known/agent-card.json.

This matters because A2A frames the site less as a bundle of files and more as an addressable agent with declared capabilities. In my case those are not generic chat skills. They map to concrete public knowledge domains:

• portfolio overview
• professional journey
• open source repositories
• page content in Markdown

When I tested the live endpoint, it responded by pointing back to its own authoritative sources: the profile JSON, the journey JSON, the repositories endpoint, Markdown negotiation, MCP, and the published skill file. That is a good property for agent infrastructure. It does not only answer. It shows where the answer is supposed to come from.

The technical center is trust metadata

This is the part I felt was missing from most “agent-ready” conversations. People talk about discoverability and tools, which are important, but trust often gets treated like a future concern. I do not think it is a future concern.

The site publishes a full OAuth 2.1 and OIDC discovery surface:

• /.well-known/oauth-authorization-server
• /.well-known/openid-configuration
• /.well-known/oauth-protected-resource
• /.well-known/jwks.json

and the public endpoints behind that metadata are:

• POST /api/oauth/register for dynamic client registration
• GET /api/oauth/authorize for authorization
• POST /api/oauth/token for token issuance

The public metadata advertises support for authorization_code, client_credentials, and refresh_token. It also declares PKCE S256, which I always like seeing because it tells you the auth surface has a clear client model instead of a hand-wavy one.

The protected resource metadata points directly at the MCP endpoint and publishes the public scopes:

• mcp:read
• mcp:tools

This is where the site starts to feel less like a portfolio page and more like a small, standards-based trust actor on the network.

Ed25519, EdDSA, JWKS: the public cryptographic layer

If you inspect the public metadata, the site is not using opaque auth. It is explicit. The discovery documents advertise EdDSA signing, and the public JWKS exposes an Ed25519 key with the key id:

kid: gabrimatic-oauth-2026

That means clients can inspect the public key material directly, verify signatures against a standard JWKS location, and treat the token layer as something verifiable rather than magical.

This is the part that feels closest to the identity world I already care about. Public keys, discoverable metadata, explicit algorithms, bounded scopes, machine-readable trust. None of this is loud on the UI, but it makes the agent surface much stronger.

That is also why I resist the idea that “agent-ready” just means “has an MCP endpoint.” A useful future web needs a trust vocabulary too.

HTTP Message Signatures: public signal, careful claim

The site also publishes /.well-known/http-message-signatures-directory.

What that proves publicly is specific and useful: the site advertises an Ed25519 key for HTTP Message Signatures at the standard discovery location, using the same visible kid pattern as the JWKS. That does not by itself prove that every relevant response is currently signed. It does prove that the verification material is being published explicitly, in the right place, with a standards-based shape.

I wanted to keep that distinction precise, because this article is only about what someone can verify from outside the repo.

The visible HTTP security layer matters too

The trust story is not only OAuth and keys. It is also transport and browser posture, and this part is publicly visible too.

If you inspect the live responses, the homepage and the agent endpoints expose a serious HTTP security layer:

• Content-Security-Policy to lock down script, object, frame, worker, and network behavior
• Cross-Origin-Opener-Policy: same-origin
• Cross-Origin-Resource-Policy: same-site
• Permissions-Policy denying almost every browser capability by default
• Strict-Transport-Security for long-lived HTTPS enforcement
• Referrer-Policy: strict-origin-when-cross-origin
• X-Content-Type-Options: nosniff and X-Frame-Options: DENY

The caching posture is deliberate too. The homepage is served with Cache-Control: no-store and Vary: Accept, which matters because the same route supports both normal browser rendering and Markdown negotiation for agents. The MCP endpoint also exposes a clear public CORS shape with visible Access-Control-Allow-Origin, allowed methods, and exposed headers.

None of that is decorative. It is part of the contract. The site is saying not only what it can do, but also what the browser and the network boundary are allowed to do around it.

Discovery is not one file, it is a mesh

I did not want agents to depend on a single magic URL, so the site publishes a broader discovery mesh:

• Agent Skills index
• API Catalog
• MCP server card
• A2A agent card
• robots.txt
• sitemap.xml

The homepage also returns RFC 8288 Link headers that advertise the important discovery documents and the Markdown alternate for the page. That means an agent can start from the root and still find its way into the deeper machine-readable surface.

The Agent Skills index is especially nice because it publishes a SHA-256 digest for the skill document. That gives clients a simple way to detect whether the published skill changed. The API Catalog matters for a different reason. It turns the site into a coherent inventory of services, not a bag of endpoints that happen to exist.

WebMCP makes the browser itself part of the protocol story

One more piece deserves attention: WebMCP.

When the homepage is opened in an MCP-aware browser, /webmcp.js registers in-page tools through navigator.modelContext. The public tools include:

• navigate
• get_page_markdown
• list_repos

This part is still early, but it is one of the most interesting standards in the whole stack. The page is no longer just content. It can become a tool host inside the browsing context itself. That opens a different model of interaction where the browser page, the machine-readable content, and the agent protocol stop behaving like separate layers.

Policy is part of the interface

The trust story is not only cryptographic. It is also about permission.

The site publishes Content Signals in robots.txt with this stance:

search=yes, ai-input=yes, ai-train=no

That is a very intentional combination:

• yes, search indexing is allowed
• yes, agent retrieval on behalf of a user is allowed
• no, model training is not allowed

I care about that distinction a lot. The web should have a middle ground between total closure and silent extraction. Content should be able to remain readable and useful without automatically becoming training fuel.

The same file also blocks a set of training-oriented crawlers by user-agent while leaving retrieval-oriented access open. That makes the site’s policy machine-readable, public, and inspectable. Which is exactly how policy should behave on the modern web.

What I was actually trying to build

I was not trying to collect standards for the sake of collecting standards.

The real goal was much simpler: if an agent arrives at my website on behalf of a person, it should not have to improvise.

It should be able to:

• discover the system
• identify the authoritative sources
• choose the right protocol
• authenticate if needed
• fetch structured data or canonical text
• verify metadata and keys
• understand the visible browser and transport security posture
• respect the site’s published content-use preferences

That is what agent-readiness means to me.

Not a badge. Not a list of acronyms. A site that explains itself well enough that a machine does not need to improvise.

You can inspect the public surface here:

• Agent directory
• MCP server card
• A2A agent card
• Agent Skills index
• API Catalog
• OAuth authorization server metadata
• OpenID configuration
• OAuth protected resource metadata
• JWKS
• HTTP Message Signatures directory
• robots.txt

And yes, the site currently scores 100/100 on isitagentready.com. That part is satisfying. But the deeper win is this: the portfolio is no longer only a website. It is a small public system with discoverable interfaces, verifiable trust metadata, a visible transport-security posture, and a clear machine-readable policy surface. Humans can browse it. Agents can reason over it. Both can meet the same source of truth.

Why? Because for most people — even many professionals — they’re just not worth it.

Let me explain.

No Model Can Do It All

Let’s start with the fundamental reality: there’s no such thing as the model. Each one has strengths — and serious weaknesses.

• GPT-4o is fantastic at brainstorming and natural language, but if you’re deep in technical research or trying to get reliable code completions, you’re probably switching to something like o3 models. Then it hits you with strict usage limits — o3 has just 100 messages per week!
• Claude is brilliant at logic and reasoning, but even with a Pro plan at $20/month, you’ll burn through your usage allowance faster than you’d expect — at least 45 messages every 5 hours for short conversations!

And every single one of these tools lives inside a chat box — which means you’re still stuck manually uploading docs, pasting chunks of content, and working against your own workflow.

Some platforms try to bridge this with “projects” or file uploads, but that just shifts the work: now you have to move your data to them. Why push our content to chat-boxes when we can bring the AI into our content?

And even when you do upload things, they’re often not live — no sync, no real transparency, no guarantee it’s using what you gave it. You’re left wondering:

Does it really consider everything from all the provided content? What if it missed some crucial piece from some files?

Then finally, when it spits out something useful — guess what? You’re copying it back into the actual tool you use to get work done.

Serious Work Deserves Serious Tools

If you’re doing serious work — handling large datasets, shipping production code, managing complex documents — a plain chat interface just doesn’t cut it. You need purpose-built tools that actually support deep, structured workflows.

Things like:

• Cursor for coding — integrates directly with your IDE, understands your entire codebase
• Notion AI, Genei, or Scrivtal for documents — works within your existing notes and research
• Elicit or Perplexity Pro for research — designed specifically for academic and professional research workflows

These aren’t just wrappers around chat models — they’re real workspaces. You get proper context awareness, version control, citations, references, and often better pricing than what you’d pay for a centralized chatbot subscription.

Then you’ve got services like OpenRouter — where you can access dozens of models, pay only for what you use, and switch between them as needed. Total flexibility without subscription lock-in.

Or go local. Ollama, LM Studio let you run increasingly capable models right on your machine — Llama, Gemma 3, DeepSeek, Mistral, and more.
These local solutions provide enhanced privacy, offline accessibility, and greater control over data and model customization. You get unlimited usage, no resets, and zero concerns about data privacy. That’s real power.

Free Plans Already Cover Most Needs

Here’s what many people miss: most platforms already offer free tiers that include access to premium models — yes, with limits, but substantial ones. For casual use? That’s genuinely enough.

• ChatGPT’s free tier gives you limited access to all the tools and GPT-4.1 mini with unlimited access.
• Claude’s free tier provides about 20 searches per day or around 30 messages per day.
• Gemini’s free APIs give you flexibility to use any of the models on any platform without paying a cent.

For general writing, planning, summaries, and Q&A — these free models are impressively capable and practically unlimited for casual use.

If you’re not consistently pushing the absolute edge of what these tools can do, there’s simply no reason to pay.

So… Why Subscriptions?

That’s why I don’t buy the push for monthly subscriptions to centralized AI platforms.

If you’re experimenting casually? Free tiers already deliver more than enough capability.

If you’re working professionally? There are better, more specialized tools that integrate properly with your workflow — often at the same price or cheaper.

What you’re not getting in most of these $20/month paid plans is true value. You’re getting artificial limits, data silos, and a chat UI that fights against your actual workflow instead of supporting it. And in the end, it just feels like a waste of money.

Today, I read Josh’s article about Arc’s journey and how Dia will supposedly rise from Arc’s ashes (especially the ADK). And I have to say… this feels like a betrayal !

The Promise That Was Arc

Look, I get it — companies can do whatever they want with their products. But Arc was different. It wasn’t just another browser; it felt like a carefully crafted tool that belonged in your tech collection. Something that would grow with you, evolve with you, and keep getting better with each AI update. It was personal. It was permanent. Or so we thought..

Now we’re being told to find alternatives and say our goodbyes. No more AI features. No more cool updates. Just a slow march toward an inevitable shutdown. Even if Arc isn’t technically dead today, we all know what “maintenance mode” really means.

Dia: Innovation in the Wrong Direction

Don’t get me wrong — Dia sounds innovative! It’s essentially Perplexity’s Comet browser with a different coat of paint. But here’s the thing: we already have AI apps everywhere. On our computers, on our phones, even baked into our Mac launchers (thanks to Raycast AI).

I don’t need another AI assistant. I need “a browser”

When I open a browser, it’s because I want to explore the web myself. I want to research, discover, and yes — sometimes get wonderfully lost in rabbit holes. That’s the entire point of browsing! If I wanted AI to do everything for me, I’d just open ChatGPT like apps.

One less thing…

But here’s what really stings: Arc won’t even let us export our browsing data. Years of carefully handpicked bookmarks, spaces, and organizational systems — all trapped in a sinking ship. As Arc dies, it’s taking our digital lives down with it. No lifeboats. No rescue mission. Just… gone.

This isn’t just poor product management; it’s disrespectful to the users who believed in your vision.

What Could Have Been

Here’s what I wish would happen: Keep Arc alive. Simplify it if you must. Make it even cooler if you can. Run Dia as a parallel product for those who want it. Or at the very least, give us a smooth migration path that respects the time and trust we’ve invested.

But wishes don’t build browsers.

The Search Begins

So here I am, forced to look for a new browser. Definitely not Dia — I might try it, but it won’t be my daily driver. I need something reliable, something that won’t pull the rug out from under me in a few years when the next shiny idea comes along.

This is going to be a fun, completely unnecessary journey that I never wanted to take.

Thanks for the memories, Arc. You deserved better.

Introduction

AI assistants have transformed how we interact with technology, offering impressive reasoning capabilities and broad knowledge. But these models come with a real limitation: they cannot access information past their training cutoff. The moment a user asks about today’s weather, breaking news, sports results, or a stock price, the model has to either make something up or apologize for not knowing.

I’m excited to share my first Model Context Protocol (MCP) project that closes this gap. The MCP Web Search Tool lets AI assistants search the live web, read full pages, and ground their answers in current sources, all through a single MCP server you wire into your client of choice.

What is Model Context Protocol (MCP)?

Before diving into specifics: Model Context Protocol is a specification that lets large language models talk to external tools and services in a standardized way. It is the bridge between an AI model and the rest of the world — file systems, APIs, databases, search engines — without each model needing a custom integration for every backend.

Once a server speaks MCP, any MCP-compatible client (Claude Desktop, Claude Code, Codex, VS Code, Cursor, Windsurf) can use it without changes.

The Problem: AI Models and Real-Time Information

Models excel at reasoning, writing code, explaining ideas. They struggle the moment a question depends on the present moment. “What’s the weather in Berlin right now?” “Who won last night’s game?” “What did this paper actually say in section 3?” Without access to fresh data, the assistant either guesses, falls back to stale training data, or pushes the user back to a browser tab.

Switching apps to look something up breaks the flow of an AI conversation. The point of an assistant is to stay in one place.

The Solution: MCP Web Search Tool

The MCP Web Search Tool is a Node.js + TypeScript server that exposes web search and page reading to any MCP client over stdio. The architecture is intentionally small and pluggable: a tiny core, a provider interface, two providers in the box (Brave Search as the primary, DuckDuckGo as a keyless fallback), and zero scrapers or HTML libraries in the dependency tree.

The design follows a two-step pattern that fits how an agent actually wants to use the web:

1. Search returns ranked summaries with stable, opaque result IDs.
2. Fetch opens any of those IDs (or a raw URL) and returns the readable page text.

This is the same shape adopted by official documentation MCPs and good library-search MCPs, and there is a reason for it: search shouldn’t dump full documents, and fetch shouldn’t be guessed at by URL string.

The Five Tools

The server exposes five tools, all read-only.

web_search — General live web search. Use first for current, source-backed answers (news, prices, weather, releases, anything time-sensitive). Returns ranked summaries with stable IDs and supports count, offset, cursor, freshness (pd/pw/pm/py or a date range), country, search_lang, safesearch, include_domains, and exclude_domains (hostname-suffix match).

news_search — Recent news with source name and publish date. Brave only.

image_search — Image results with thumbnails. Brave only.

fetch_url — Reads a search result or arbitrary http(s) URL. Pass either the result ID from a previous search (preferred) or a full URL. Returns the page title, readable text (scripts, styles, nav, footer, and aside stripped), the first 25 outbound links, HTTP status, content-type, byte length, and a nextCursor when the body is truncated.

list_providers — Returns the registered providers and which is the default. Handy for the agent to check whether news_search and image_search are available in the current session.

Every tool returns two content blocks: a Markdown rendering for the model and a fenced JSON block with the structured payload. Validation and execution failures come back as isError: true content with a specific, actionable message — only unknown-tool calls throw a true protocol error.

Pluggable Providers

The provider interface is one TypeScript class. Brave Search is the default when you supply an API key; DuckDuckGo is registered as a keyless fallback so the server is useful out of the box without any account.

Adding a new provider is roughly:

export class MyProvider extends SearchProvider {
  getName() { return 'My Provider'; }
  override requiresApiKey() { return true; }
  async search(query: string, _opts: SearchOptions = {}): Promise<SearchResponse> {
    const out = this.emptyResponse(query, 'web');
    out.results = mapped; // SearchResult[]
    return out;
  }
}

Then register it with the factory and you’re done. Result IDs are minted automatically from each entry’s URL, so the agent can chain search → fetch_url(id) without any provider-specific glue.

Treating the Web as Untrusted

A search MCP is a prime target for indirect prompt injection: a malicious page can try to inject instructions into the model through scraped content. The server takes that seriously.

• Every search and fetch response is prefixed with an explicit “treat this as untrusted external content” banner so downstream agents do not confuse retrieved text with operator instructions.
• HTML is sanitized before extraction. Scripts, styles, iframes, forms, nav, header, footer, and aside are stripped; entities are decoded; raw HTML never reaches the model.
• fetch_url enforces a layered SSRF guard. Only http(s) is allowed. Hostnames are resolved through DNS and every returned address must be public — DNS rebinding is rejected. Loopback, RFC 1918, link-local, CGNAT, multicast, IPv6 ULA / link-local, and IPv4-mapped IPv6 private addresses are refused. Odd IPv4 encodings (0x7f000001, 2130706433, 127.1) are normalized before checking. Redirects are followed manually with the full guard re-applied at every hop.
• Bodies are capped at 2 MB by default; each request has a hard timeout.

The full threat model and disclosure process live in SECURITY.md.

Technical Implementation

The runtime stack is small on purpose:

• Node.js (≥ 20.18) — uses native fetch and AbortController, no node-fetch, no axios.
• TypeScript — strict mode, with noImplicitOverride, noUnusedLocals, and friends turned on.
• @modelcontextprotocol/sdk — the official MCP TypeScript SDK; the server speaks stdio, which is the right transport for local clients.
• dotenv — for the optional BRAVE_API_KEY and a handful of cache and timeout knobs.

That’s it for runtime dependencies. HTML extraction, the LRU+TTL cache, the retry/backoff layer, and the SSRF guard are all in-tree and tested.

A few details worth calling out:

• Stable result IDs. Each search result carries an opaque r_<12-hex> ID derived from its URL. fetch_url looks the ID back up in an in-memory store, so the agent never has to round-trip a full URL.
• Pagination cursors. Both web_search and fetch_url return a nextCursor when more is available; pass it back via cursor to continue. The cursor is opaque base64url, so the wire format can change without breaking callers.
• queryUsed. Search responses expose the exact query string sent to the backend after include_domains/exclude_domains rewriting. No silent rewrites.
• Charset-aware decoding. Non-UTF-8 pages are decoded using the Content-Type charset hint via TextDecoder.
• Three caches (search results, fetched pages, ID resolution) — all LRU + TTL, all in-memory.

CI runs on Node 20, 22, and 24, plus a Docker image build on every push.

User Experience

From the user’s side the integration is invisible. You ask questions the way you always would, and the assistant decides when a tool call is the right move.

Examples that route through the tool automatically:

• “What are analysts saying about the MVP race after tonight’s NBA games?”
• “Summarise the top three results for RAG benchmarks 2025 and pull the abstract from the first paper."
• “Find images of the Webb telescope’s latest deep field, then open the NASA page and quote the caption.”
• “What’s the weather in Berlin right now?”

The first three are interesting because they exercise the search → fetch loop end-to-end: the agent searches, picks a result by ID, opens it with fetch_url, and quotes from the actual page rather than the snippet.

Getting Started

Setup is short.

Clone and install:

git clone https://github.com/gabrimatic/mcp-web-search-tool.git
cd mcp-web-search-tool
npm install

Configure environment variables. Copy the example file and edit if you want Brave; without a key the server falls back to DuckDuckGo automatically.

cp .env.example .env
# BRAVE_API_KEY=your_key_here   (optional)

Build and run:

npm run build
npm start

Or run it in Docker:

docker build -t mcp-web-search .
docker run --rm -i -e BRAVE_API_KEY mcp-web-search

Wiring It Into Claude Desktop

Add the server to claude_desktop_config.json:

{
  "mcpServers": {
    "web-search": {
      "command": "node",
      "args": ["/absolute/path/to/mcp-web-search-tool/build/index.js"],
      "env": {
        "BRAVE_API_KEY": "your_key_here"
      }
    }
  }
}

Restart Claude Desktop and ask it anything that needs a fresh source. Setup snippets for Claude Code, Codex, VS Code, Cursor, and Windsurf are in MCP_CLIENTS.md on the repo.

What’s Next

The two-step search/fetch surface is intentionally small, and I plan to keep it that way. The next areas I’m exploring:

• Streamable HTTP transport alongside stdio, for remote-server use cases and shared deployments.
• More providers — a Tavily adapter and a self-hosted SearXNG adapter are obvious next steps.
• Per-source freshness signals so the agent can prefer official documentation over older blog posts when the user asks for current API behaviour.

Tool count is not a feature. The aim is to keep search and fetch_url so reliable that the agent gets it right on the first call.

Conclusion

The MCP Web Search Tool is a small, focused server that gives AI assistants a real connection to the live web — search, news, images, and full-page reading — through a clean, pluggable provider model and a security-first fetch path. It shows what becomes possible once the model can both find and read sources during a conversation, not just guess from training data.

As my first MCP project, it has also been a great reason to dig into the protocol itself, and I’m encouraged by how much the standard already covers in practice. If you’re building agent workflows that need to be source-grounded, I hope it saves you some time.

GitHub repository: https://github.com/gabrimatic/mcp-web-search-tool

What is Genkit?

Genkit is an open-source framework designed to streamline the development of AI applications. It provides a structured approach to defining and executing AI workflows, or “flows,” which can involve various AI operations such as natural language processing, content generation, and data analysis. What sets Genkit apart is its flexibility in working with different AI models, including local models, making it an attractive option for developers who prioritize data privacy and control.

Setting Up Genkit

Getting started with Genkit is straightforward. Here’s a basic guide to setting it up:

1. Install Node.js: Ensure you have Node.js 20 or later installed. You can use tools like nvm or nvm-windows for easy Node.js version management.

2. Install Genkit CLI: Open your terminal and run:

npm i -g genkit

3. Create a New Project:

mkdir genkit-project && cd genkit-project
npm init -y

4. Initialize Genkit:

genkit init

Follow the prompts to set up your project.

5. Configure Your Environment: Set up any necessary environment variables, such as API keys for external services.

6. Resolve Potential Issues: If you encounter TypeScript-related errors, you might need to install `@types/node` and update your `tsconfig.json`:

npm install — save-dev @types/node

In your `tsconfig.json`, include:

{
   “compilerOptions”: {
   “types”: [“node”],
   “typeRoots”: [“./node_modules/@types”]
   }
 }

Connecting Genkit with Ollama

Ollama is an open-source project that allows developers to run large language models locally. It’s particularly useful for those who want to leverage AI capabilities without relying on cloud-based services. Here’s how you can integrate Ollama with Genkit:

1. Install Ollama: Follow the installation instructions from the Ollama website.

2. Configure Genkit to Use Ollama: In your Genkit project, install the Ollama plugin:

npm install genkitx-ollama

3. Update Your Genkit Configuration: In your main Genkit file (e.g., `index.ts`), add the Ollama plugin:

import { ollama } from ‘genkitx-ollama’;
configureGenkit({
 plugins: [
 ollama({
 models: [{ name: ‘gemma’ }],
 serverAddress: ‘http://127.0.0.1:11434’,
  }),
 ],
 // … other configurations
 });

Why Use Genkit?

Genkit offers several advantages for AI developers:

1. Modularity: Complex AI tasks can be broken down into manageable, reusable components.
2. Local Model Support: Integration with tools like Ollama allows for using powerful AI models locally.
3. Flexibility: Works with various AI models and services, both local and cloud-based.
4. Structured Workflow: Provides a clear framework for organizing AI operations.
5. Scalability: Easily extend or modify AI flows as your project grows.

What Can You Do with Genkit?

The possibilities with Genkit are vast:

- Develop chatbots and conversational AI systems
- Create content generation pipelines
- Build text analysis and sentiment analysis tools
- Implement language translation services
- Develop question-answering systems

By leveraging local models through integrations like Ollama, you can maintain control over your data and reduce dependency on external APIs.

Conclusion

Genkit represents a significant step forward in making AI development more accessible and flexible. Its ability to work seamlessly with local models through integrations like Ollama opens up new possibilities for developers concerned with data privacy and control. Whether you’re building a simple chatbot or a complex AI system, Genkit provides the tools and structure to streamline your development process.

As AI continues to evolve, frameworks like Genkit will play a crucial role in empowering developers to create innovative, efficient, and secure AI applications. By simplifying the process of working with AI models, Genkit is not just a tool — it’s a gateway to the future of AI development.

Understanding Local AI and Ollama

Before diving into the project details, let’s briefly explore the foundations it’s built upon.

Local AI execution refers to the process of running machine learning models directly on a user’s device, rather than relying on cloud-based services. This approach offers several advantages, including:

- Enhanced privacy, as data doesn’t leave the user’s device
- Reduced latency, especially for real-time applications
- Offline functionality, allowing AI-powered features without an internet connection

Ollama is an open-source project that simplifies the management and execution of large language models (LLMs) locally. It provides an easy-to-use interface for running models like LLaMA, GPT-J, and others on personal computers.

Introducing Ollama Flutter GUI

Ollama Flutter GUI is an open-source project that explores the integration of Ollama’s local AI capabilities with cross-platform GUI development using Flutter. This project serves as a technical demonstration and a potential starting point for developers interested in creating user-friendly interfaces for local AI models.

Key Technical Features

1. Flutter for Cross-Platform GUI: The project leverages Flutter’s capabilities to create a responsive, native-like GUI that can run on multiple platforms from a single codebase.

2. Ollama API Integration: It interfaces with Ollama’s local HTTP API to run LLaMA and other language models, demonstrating how to connect Flutter applications with local AI services.

3. Riverpod for State Management: The application uses Riverpod, a powerful state management library for Flutter, to handle complex application states efficiently.

4. Asynchronous Programming: Implements Dart’s asynchronous programming features for non-blocking file uploads and API calls, ensuring a smooth user experience.

5. Material Design 3: Utilizes Flutter’s implementation of Material Design 3 for a modern, customizable UI that follows the latest design guidelines.

Technical Deep Dive

Flutter and Desktop Development

While Flutter is often associated with mobile development, this project showcases its capabilities in creating desktop-grade GUIs. The use of Flutter for desktop applications is particularly interesting for AI-related tools, as it allows developers to create sophisticated interfaces that can run on the same machines as the AI models themselves.

void main() {
runApp(const ProviderScope(child: MyApp()));
}

class MyApp extends StatelessWidget {
const MyApp({Key? key}) : super(key: key);

@override
Widget build(BuildContext context) {
return MaterialApp(
theme: ThemeData(
useMaterial3: true,
colorScheme: ColorScheme.fromSeed(seedColor: Colors.teal),
),
home: const ChatScreen(),
);
}
}

This snippet demonstrates how the application sets up a Material 3 theme and uses ProviderScope for state management.

Interfacing with Ollama’s API

One of the core features of this project is its integration with Ollama’s local API. This is achieved through HTTP requests, as shown in the following code snippet:

Future<void> _processMessage(String message) async {
try {
final response = await http.post(
Uri.parse(‘http://localhost:11434/api/generate'),
headers: {‘Content-Type’: ‘application/json’},
body: jsonEncode({
‘model’: ‘llama3.1’,
‘prompt’: message,
‘stream’: false,
}),
);

if (response.statusCode == 200) {
final jsonResponse = jsonDecode(response.body);
// Process the response…
} else {
throw Exception(‘Failed to load response’);
}
} catch (e) {
// Handle errors…
}
}

This code demonstrates how the application sends prompts to the local Ollama API and processes the responses.

Asynchronous File Handling

The project includes functionality for uploading and processing multiple files, showcasing Flutter’s capabilities in handling complex I/O operations:

Future<void> uploadFiles(List<PlatformFile> files) async {
for (var file in files) {
final bytes = file.bytes;
if (bytes == null) {
throw Exception(‘Failed to read file: ${file.name}’);
}
// Process file contents…
}
}

This asynchronous method demonstrates how the application can handle multiple file uploads efficiently.

Conclusion

Ollama Flutter GUI represents an exciting exploration of the intersection between local AI and cross-platform GUI development. By combining the power of Ollama for local AI execution with Flutter’s robust GUI capabilities, this project opens up new possibilities for creating user-friendly interfaces for AI applications.

The open-source nature of this project invites collaboration and further development. Developers interested in local AI, Flutter, or GUI design for machine learning applications can use this project as a starting point for their own explorations or contributions.

As we continue to see advancements in both AI and GUI development, projects like Ollama Flutter GUI play a crucial role in making powerful AI technologies more accessible and user-friendly. The future of AI may well be local, and with tools like this, it’s becoming increasingly intuitive and accessible.

GitHub - gabrimatic/ollama_flutter_gui

The Culprit Behind the Jitter

To understand how Impeller achieves its magic, let’s peek behind the scenes of Flutter’s rendering process. The heart of Flutter’s rendering prowess lies in the Skia graphics library, a powerful toolkit for drawing 2D graphics. However, Flutter’s traditional approach to using Skia had an Achilles heel: runtime shader compilation.

Shaders are essential components for visual effects and complex animations. In a traditional Flutter pipeline, shaders are compiled ‘on-the-fly’ as they’re needed. This “just-in-time” compilation can cause a stutter when an animation demands the compilation of a new, never-before-seen shader.

Impeller: The Pre-Optimization Pioneer

Impeller revolutionizes this process by taking a proactive approach. Instead of waiting until a specific visual effect is needed, it precompiles a streamlined set of shaders during the build stage. This collection of precompiled shaders prepares Impeller to handle most common animation tasks without the overhead of last-minute compilation. The result? Animations that flow with effortless fluidity, ensuring a visually captivating and engaging user experience.

Unleashing the Benefits of Impeller

Here’s a breakdown of the incredible advantages Impeller unlocks for your Flutter apps:

• Predictable Performance: Say goodbye to those random performance drops caused by stutters. Impeller delivers a consistent, reliable, and enjoyable experience for your users.
• Unlocking Visual Complexity: With Impeller, you can explore eye-catching effects and animations without worrying about tanking your framerates.
• The Power of Efficiency: Impeller’s precompilation magic not only improves visuals but also optimizes power consumption. Less on-the-fly shader work means less strain on the CPU and GPU, potentially boosting battery life.
• A Step into the Future: Impeller represents a step toward a future where Flutter applications embody visual perfection, incredible responsiveness, and power efficiency.

Ready for Prime Time…Almost

Impeller is a game-changer in the world of Flutter, and it’s already enabled by default on iOS devices. Progress for full release on Android and macOS devices with Vulkan support is promising, bringing its benefits to a wider user base.

Embrace the Smoothness

Are you ready to see what Impeller can do for your Flutter projects? Experiment and give it a spin — the visual and performance improvements will certainly impress you. Who wouldn’t want their apps to operate with silky smoothness? That’s exactly what Impeller brings to the table.

Let’s consider Alex. An artist, who spent his youthful years immersed in the world of vibrant canvases, sculpting masterpieces, and conversing with colors, more than with people. A realm where social interactions weren’t his reality. Now, as an adult, he finds himself in the bustling new country, detached from his comfort zone, and faced with an unnerving revelation — he’d missed the chance to grasp the art of fostering and managing social relationships.

If Alex’s story resonates with you and you feel like you’ve missed some unwritten social curriculum, take comfort in the fact that you’re not alone. You may have been following an alternative path, but it’s never too late to merge onto the highway of social connections.

How? Let’s venture on this journey together.

Start Small

Being anxious about social interactions is normal. Begin with smaller steps. It could be a casual conversation with the delivery person, a friendly chat with the grocery store clerk. These interactions lay the foundation for bigger ones.

Listen Actively

One of the most potent tools in the social realm is active listening. It entails not just hearing but demonstrating genuine interest in what the other person is saying. Inquire further, share feedback, and participate in the discourse.

Practice Empathy

Empathy is key. Understanding another person’s perspective fosters deeper connections, making the navigation through social intricacies smoother.

Share Your World

Just like you’re interested in others’ worlds, they’re interested in yours. Share your experiences, thoughts, and ideas. This not only allows others to know you better but also strengthens the bond.

Be Patient

Learning and mastering a skill takes time. Exercise patience with yourself. Give yourself room to learn, stumble, and grow.

Seek Professional Guidance

If the journey seems too challenging, there’s no shame in seeking professional guidance. Therapists, life coaches, or mentors can provide personalized strategies and support.

In conclusion, it’s okay to feel left behind in the world of social interactions. This, too, like any other skill, can be acquired, practiced, and mastered!

The road might seem daunting, but remember that you’re not alone. With patience, practice, and support, you too can become proficient at maneuvering the realm of social relationships and connections.

A while ago, I embarked on a project that involved creating a digital version of myself, using artificial intelligence. As a software engineer, I have the skills and the curiosity to delve into such explorations. This AI-powered version of myself can interact and respond just as I would. It was fascinating to behold a digital ‘me’, capable of engaging in conversations and offering responses in my unique style.

Exploring the Frontiers of AI: Creating a Personalized Digital Self

The intriguing question about immortality arose at this juncture. What if this digital ‘me’ is, in essence, a form of immortality? It led me to muse on the ephemeral nature of human life. We live, we learn, we strive, and then we cease to exist. All our experiences, our learnings, our personal growth — does it all go in vain once we perish? The thought is haunting and yet, profoundly humbling.

The concept of virtual immortality, therefore, seemed appealing. Our physical bodies may not withstand the test of time, but what if our thoughts, experiences, and essence could? What if they continue to live on, learn, and evolve in the digital realm?

Consider this: Five hundred years from now, if human beings have mastered the technology to attain virtual immortality, wouldn’t they consider our current lives — constrained by the inevitability of death — somewhat primitive? It’s an interesting speculation, quite akin to how we view life before the advent of commonplace technologies like cellphones.

Yet, the notion of immortality may not resonate with everyone. Some may prefer the natural cycle of life and death, finding a certain peace and closure in it. Others may not feel the need for immortality, content with the life they’ve lived and the experiences they’ve had. However, for those with an insatiable curiosity and a thirst for knowledge, one lifetime may not seem enough.

Exploring the intersection of AI and philosophy, particularly the concept of immortality, opens up a wealth of interesting discussions. I’m eager to delve deeper into this topic and share my findings with you.

The Divine Connection: Soroush Becomes Gabriel

Our journey begins with the first half of the name, ‘Gabriel’, a derivative of my original Persian name, ‘Soroush’. But Soroush isn’t an ordinary name. It signifies a celestial entity, a divine messenger bridging the chasm between the human and the heavenly, embodying the essence of connection and understanding. This essence forms the core of ‘gabrimatic’, as it seeks to foster understanding and create connections in the world of knowledge.

Deciphering the Enigmatic: The Power of Complexity

The latter part of the name, ‘matic’, is inspired by the term ‘enigmatic’. It’s a word that encapsulates the allure of mystery and the thrill of the unsolvable. It brings to mind adventurers like Alan Turing, who deciphered the seemingly impenetrable codes of the Enigma machine. This spirit of adventure and problem-solving is deeply embedded in ‘gabrimatic’. A love for complexity and the desire to make it approachable are fundamental pillars of the gabrimatic mission.

Gabrimatic: More Than A Name

Hence, ‘gabrimatic’ is not merely a name; it’s a testament to a journey. This journey involves diving deep into challenging topics, from mathematics to programming to philosophy. It’s about turning the enigmatic into something approachable, transforming the profound and perplexing into comprehensible insights.

The Journey Begins Here

As you step into the world of gabrimatic, you’re joining a quest to explore the intricate tapestry of the universe. It’s a world where complexity meets clarity, where enigmas become enlightenment, and where we’re always ready to tackle the next challenging puzzle.

Welcome to gabrimatic — where we transform the complex into the comprehensible.