Coder Legion - Recent posts tagged public

Do You Need llms.txt? AI Crawler Controls Explained

Fri, 25 Sep 2026 15:50:00 +0000

Direct answer: publish /llms.txt only if you maintain a documentation-heavy or structured knowledge site and can keep a curated machine-readable map accurate. For an ordinary service business, prioritize crawlable pages, internal links, a clean sitemap, correct structured data, and explicit crawler rules.

The distinction matters because llms.txt and robots.txt solve different problems. The llms.txt proposal describes a Markdown overview for use at inference time. Its own specification says it complements existing standards. It does not define access permission or an opt-out mechanism.

Use the control that matches the job

Control	Actual job	What it cannot promise
`robots.txt`	Tell compliant crawlers which paths they may request	Removal from search, privacy, or universal enforcement
`llms.txt`	Offer a curated Markdown description and links	Crawler access, training opt-out, ranking, or citation
`sitemap.xml`	List preferred indexable URLs for search discovery	Indexing or selection in an AI answer
`noindex` and snippet controls	Control indexing or how much Google may show from a page	A safe result when the crawler is blocked from reading the directive
CDN or WAF rules	Permit or deny requests at the infrastructure layer	Correct intent if rules rely only on a spoofable user-agent string

Do not treat a public text file as a privacy boundary. Never list private dashboards, customer portals, staging hosts, unpublished documents, or sensitive paths in llms.txt. Protect them with authentication and access controls.

What llms.txt is

The proposal places a Markdown file at /llms.txt. It starts with one required H1, may include a short summary and explanatory text, and can group useful links under H2 headings. The specification also proposes optional Markdown versions of detailed pages.

That can be useful for a software library, API, public knowledge base, or complex documentation set. A maintainer can point an agent toward a stable quick start, current reference, examples, and known limitations without asking it to infer the hierarchy from navigation and decorative HTML.

The proposal does not specify how an AI provider must discover, fetch, or use the file. It explicitly leaves processing decisions to each application. That is why publishing the file is an experiment, not an access-control project.

Why most small-business sites do not need it

A typical service site has a homepage, service pages, a few decision guides, contact information, and perhaps a local profile. Those pages should already explain the business clearly in rendered HTML. Adding another summary file creates a second place where services, locations, prices, policies, and URLs can become stale.

Google's official guidance is especially direct. Pages need normal Search eligibility for AI Overviews and AI Mode, and Google says no new machine-readable file, AI text file, or special markup is required. Googlebot access, indexability, internal discovery, visible text, page experience, and accurate structured data remain the foundation.

Site situation	Recommendation	Reason
Local or service business	Skip it for now	Improve the actual service pages and crawler access first
Small editorial site	Usually skip it	The sitemap, hubs, and contextual links already express the library
Large public documentation set	Consider a test	A curated route can reduce ambiguity for tools that choose to read it
API or developer product	Consider a generated file	Versioned references and examples may benefit from a concise machine-readable index
Site with weak crawlability	Fix access first	An optional file cannot repair blocked pages, bad status codes, or a hostile WAF

Separate search retrieval from model training

There is no single universal "AI bot" switch. Vendors document separate agents for different jobs, and a site owner may want search visibility without allowing potential training use.

Provider	Search or user retrieval	Separate control
Google	`Googlebot` controls Search, including AI Overviews and AI Mode	`Google-Extended` controls certain Gemini training and grounding uses outside Google Search
OpenAI	`OAI-SearchBot` supports ChatGPT search discovery	`GPTBot` is the published control for potential training
Anthropic	`Claude-SearchBot` and `Claude-User` support search and user-directed retrieval	`ClaudeBot` is used for content that could contribute to model training
Perplexity	`PerplexityBot` supports search results; `Perplexity-User` supports user-requested fetches	Perplexity says these two agents are not used to train foundation models

Google states that blocking Google-Extended does not affect inclusion or ranking in Google Search. OpenAI's publisher guidance similarly separates OAI-SearchBot from GPTBot. Anthropic documents three distinct agents so publishers can make separate choices.

Build the policy before editing robots.txt

Write the business decision first. Otherwise a copied rule can quietly block the exact search surface you intended to keep.

List the public content: decide which pages may be retrieved by search and user-directed agents.
Separate model development: decide whether to block training-specific agents where a vendor provides that control.
Protect private content properly: use authentication, authorization, network restrictions, or removal. Do not rely on crawler courtesy.
Inspect the whole delivery path: robots.txt, CDN, WAF, hosting firewall, rate limits, JavaScript challenges, and origin responses can disagree.
Record an owner and review date: crawler names, IP ranges, and product behavior change.

The AI search citation guide covers content eligibility and evidence after access is working. The technical SEO fixes guide covers infrastructure problems that ordinary content edits cannot solve.

A cautious robots.txt example

This example expresses one specific policy: allow documented search agents, block documented training controls, and leave normal search crawling open. It is not a universal recommendation. Read every vendor's current documentation and your existing robots file before adapting it.

User-agent: *
Allow: /

User-agent: OAI-SearchBot
Allow: /

User-agent: GPTBot
Disallow: /

User-agent: Claude-SearchBot
Allow: /

User-agent: ClaudeBot
Disallow: /

User-agent: PerplexityBot
Allow: /

User-agent: Google-Extended
Disallow: /

Sitemap: https://example.com/sitemap.xml

This does not remove a page from search. A robots disallow can prevent a crawler from seeing a noindex directive on the blocked page. If removal is the goal, follow the search engine's documented removal or indexing controls instead of combining random directives.

It also does not create a hard security block. Robots rules are instructions for compliant agents. A scraper can ignore them, and a legitimate agent can still be stopped by an overly broad firewall rule.

Check the CDN and WAF separately

Allowing a crawler in robots.txt is only the first gate. OpenAI and Perplexity both tell publishers to check CDN, WAF, bot mitigation, response codes, and published IP ranges when access fails. Perplexity recommends combining the expected user agent with its current IP list rather than trusting the header alone.

A safe validation sequence is:

Request the live /robots.txt and confirm the deployed file matches the policy.
Request representative public URLs with the documented user-agent token.
Confirm a successful response, useful HTML, and no challenge page.
Inspect CDN and origin logs for 401, 403, 429, redirect loops, and unusually large responses.
Where the vendor publishes IP ranges, verify both the header and source range before creating an allow rule.
Recheck after deployment because caches and crawler processing can delay the observed change.

curl -I -A "OAI-SearchBot" https://example.com/important-page
curl -I -A "Claude-SearchBot" https://example.com/important-page
curl -I -A "PerplexityBot" https://example.com/important-page

A forged user-agent can pass this simple request test. Use it to find obvious blocks, not to authenticate crawler identity.

When an llms.txt test is worth maintaining

Consider a limited test when all of these conditions are true:

the public site contains a large, stable documentation or knowledge corpus;
the preferred entry points and current versions are difficult to infer from navigation alone;
the file can be generated from the same source of truth as the documentation;
every linked URL is public, canonical, useful, and maintained;
the team can test named tools or agents instead of treating the file as a universal standard;
removing the experiment would not damage ordinary crawling, indexing, or user navigation.

If you publish it, keep the file concise. Name the project, explain the scope, link only to preferred public resources, and record how it is generated. Do not paste your sitemap into Markdown or duplicate full pages into a second unmanaged content layer.

What not to do

Do not use llms.txt as an opt-out file. Use each provider's documented crawler token and access controls.
Do not block every AI-related token. A training control and a search bot may have different jobs.
Do not list sensitive paths. Public crawler files are not a substitute for authentication.
Do not create a stale second website map. Generate the file from maintained data or do not publish it.
Do not expect a citation lift. Access and context create eligibility, not selection.
Do not trust a user agent by itself. Use official IP data and logs when infrastructure policy depends on identity.
Do not let the experiment delay basic SEO. Fix status codes, internal links, canonicals, sitemaps, rendered text, and page quality first.

FloxoLab's current decision

FloxoLab does not need llms.txt to make its guides eligible for Google AI features or ChatGPT Search. The current priorities are a crawlable public library, one canonical URL per task, accurate metadata, responsive media, contextual links, and explicit crawler access.

A generated file may become worth testing after the SEO guide library expands and the filterable hub is stable. If that happens, the file should be derived from the content manifest, not maintained as another hand-written index. The topic-cluster guide explains why one source of truth matters when a library grows.

Decision checklist

The business goal is written before crawler rules are changed.
Search retrieval and potential training are treated as separate decisions.
Private content is protected with real access controls.
robots.txt, CDN, WAF, and origin behavior agree.
Official crawler documentation and IP sources were checked recently.
Important public pages return useful HTML to allowed agents.
An llms.txt experiment has a narrow purpose, owner, generator, and removal plan.
No ranking or citation outcome is promised.

For most small businesses, the right answer is simple: skip llms.txt for now, make the real pages easy to crawl and understand, and control each crawler according to the job it performs.

Sources checked

Behavior and crawler names were verified from primary or official documentation on August 2, 2026.

Need a crawler-access review?

I can review robots rules, CDN and WAF behavior, indexability, structured data, and AI-search access without selling an experimental file as a ranking shortcut.

Request an SEO audit

Originally published on FloxoLab.

How to Respond to Negative Google Reviews in the Philippines

Sat, 19 Sep 2026 15:50:00 +0000

Direct answer: acknowledge the review without arguing, confirm only facts you can safely make public, invite the reviewer to a private channel, and record the operational follow-up. If the review appears to violate Google Maps policy, preserve the evidence and report it, but do not report it merely because it is harsh or disputed. Never reveal an order history, medical detail, payment record, phone number, address, or employee file in the public reply.

A useful response is written for two audiences. The reviewer needs a clear route to resolution. Future customers need to see that the business listens, protects privacy, and fixes problems without turning the review section into a courtroom. This guide owns that single-incident response. The broader process for requesting, monitoring, assigning, and learning from reviews belongs in the separate review-management guide.

You need a verified Google Business Profile before you can reply. Google says an approved reply is posted publicly under the review, the reviewer is notified, and the reviewer may edit the review afterward. That makes a calm first response more useful than a fast emotional one. It does not guarantee a changed rating or removal.

Classify the review before choosing the response

What you see	Primary action	Public response
A recognizable service failure	Verify the event, assign an owner, and offer a specific private route	Acknowledge the experience and state the next step without exposing the record
A complaint you cannot match	Search by date, branch, service, and limited reference data	Say you could not identify the case from the public details and invite direct contact
Off-topic, fake engagement, impersonation, harassment, or exposed personal information	Capture evidence and report the policy category that actually applies	Reply only if a short privacy-safe clarification helps customers while the report is reviewed
A threat, extortion attempt, safety issue, or legal claim	Preserve evidence and escalate internally to the appropriate adviser or authority	Usually pause. Do not negotiate, accuse, or publish evidence in the review thread
A genuine opinion you strongly disagree with	Check whether a process or expectation failed	Respond to the experience. Do not demand removal or describe opinion as a policy violation

Google's removal standard is policy-based. Its Business Profile guidance says only reviews that violate policy are eligible for removal, and that a business should not report a review just because it dislikes or disagrees with it. A negative account can remain even when your internal record tells a different story.

1. Preserve the evidence and slow the response down

Save the review URL if available, reviewer name as displayed, rating, text, images, publication time, profile location, and a screenshot. Record who discovered it and when. If the text is later edited or removed, you still need an internal record of the original incident and the action taken.

Assign one response owner. A restaurant shift lead, clinic coordinator, or branch manager can gather facts, but only the designated person should publish the reply. This prevents parallel answers and makes the tone consistent. For an ordinary complaint, responding later the same business day or the next day is usually better than answering before the relevant staff can be heard.

Pause immediately when the review contains a threat, extortion demand, doxxing, or sensitive personal information. Limit internal access, preserve the evidence, and use the appropriate policy, safety, legal, or privacy escalation. Do not quote the harmful details in your reply.

2. Investigate with the minimum necessary data

Start with the smallest useful search: branch, service type, approximate date, staff on duty, and a non-sensitive reference the reviewer can provide privately. Ask the staff member what happened before deciding that the review is false. Separate facts from assumptions in the case note.

Review URL:
Profile / branch:
Received at:
Assigned owner:
Classification:
Verified facts:
Facts not yet verified:
Customer data consulted:
Public reply approved by:
Private follow-up channel:
Policy report / appeal status:
Operational correction:
Closed at:

In the Philippines, the National Privacy Commission's implementing rules require personal-data processing to follow transparency, legitimate purpose, and proportionality. The rules also say data should be adequate, relevant, and limited to what is necessary. Applied here, a public review does not authorize the business to publish everything it knows about the reviewer. Use private records to resolve the case, not to win a public argument.

3. Write a short public response

A strong first reply normally has four parts:

Acknowledge the experience. Thank the person for raising it or state that you are sorry the visit did not meet expectations.
State the standard or concern. Name the relevant service expectation without making an unverified admission.
Protect privacy. Explain that the team will not discuss customer details in a public thread.
Offer one owned route. Give a monitored email, phone line, or contact form and say what reference will help privately.

Do not paste the same generic paragraph under every complaint. Keep the structure consistent, but refer to the actual service category, branch, or issue when doing so is safe. The reply should be complete enough for an observer to understand the next step without exposing the investigation.

Response templates for common cases

Recognizable service problem

Thank you for raising this. I am sorry the visit did not meet the service standard we aim for. We are reviewing what happened with the team. To protect your privacy, please contact [monitored channel] with your visit date and reference number so [owner or role] can follow up directly.

Complaint you cannot match from the public details

We take this feedback seriously, but we have not been able to identify the visit from the details posted here. Please contact [monitored channel] with the date, branch, and reference number. We will review it privately and respond through that channel.

Privacy-sensitive business

Thank you for bringing this to our attention. We cannot discuss client records or service details in a public review. Please contact [privacy-safe channel] and ask for [role] so we can verify the matter and address it directly.

Review appears to describe another branch or business

We would like to check this carefully. The service described does not appear to match the records available to this location, but we will not make assumptions in public. Please contact [channel] with the date and branch so we can confirm where the issue belongs.

Replace the brackets with a channel that is actually monitored. Do not ask the reviewer to post an order number, phone number, full name, medical detail, or other personal data in the review thread.

4. Decide whether to report the review

Use the Google Maps prohibited and restricted content policy as the decision source. Relevant categories can include fake engagement, impersonation, off-topic content, harassment, doxxing, personal information, profanity, and unsubstantiated allegations of criminal or unethical conduct. Select the category supported by the content. Do not invent a privacy or spam reason simply because the business cannot find the customer.

Google provides reporting from the Business Profile and through its Reviews Management Tool. Its current help page says review evaluation typically takes several days. If the result is "no policy violation," the tool can offer a one-time appeal. The appeal is for a policy decision, not a second attempt to settle a factual disagreement with the reviewer.

Capture the review and the exact policy clause you believe applies.
Report the review from the profile or Reviews Management Tool.
Record the submission date and status in the incident note.
If eligible, use the one-time appeal with a concise policy explanation.
Continue the service-recovery process separately when a real customer issue may still exist.

If the review contains an extortion demand tied to removal or threatened reviews, use Google's dedicated extortion-reporting route linked from the inappropriate-review help page. Preserve messages and payment demands. Do not pay, bargain in public, or coordinate retaliatory reviews.

5. Move the resolution off the public thread

The private conversation should have an owner, a deadline, and a remedy boundary. Confirm the issue, explain what can and cannot be changed, and document the agreed action. A refund, replacement, correction, apology, or staff follow-up may be appropriate depending on the facts and the business's policy. Do not make compensation conditional on deleting or improving the review.

If the customer confirms the matter is resolved, you may politely say that they are free to update the review if they believe the new outcome changes their experience. Do not script the rating, offer an incentive, or pressure them. Google treats reviews influenced by payment, discounts, free goods, services, or conflicts of interest as incentivized or biased content.

6. Close the internal action, not just the conversation

A response without an operational correction is reputation theatre. Tag the root cause so recurring failures become visible: wait time, staff communication, billing, stock, handoff, cleanliness, scheduling, product quality, or expectation setting. Record the fix owner and the date it will be checked.

For one incident, a small case log is enough. When reviews arrive regularly, move from ad hoc replies to the full Google review management process for fair requests, monitoring, assignment, service recovery, and trend review. Build the workflow before buying software for it.

What not to do

Do not argue line by line. A long rebuttal gives private evidence a public audience and makes the business look defensive.
Do not identify the customer from internal records. Matching a username to an order does not give permission to publish the connection.
Do not promise removal. Google decides policy enforcement, and a compliant negative opinion may remain.
Do not accuse the reviewer of lying. Say what you could or could not verify, then provide a private route.
Do not threaten legal action in the reply. Preserve evidence and obtain appropriate advice away from the public thread.
Do not offer money, discounts, or free service for a changed rating. Resolve the service issue without buying the review outcome.
Do not outsource replies without access controls. An agency should not receive more customer data or profile permissions than the task requires.

Verify the response and follow-up

The reply appears under the correct profile and review.
No personal, medical, payment, employment, or order details are public.
The contact channel works and reaches the named owner.
The internal note separates verified facts from claims and assumptions.
Any Google report cites a real policy category and has a recorded status.
The service correction has an owner and review date.
The team checks whether the reviewer edited the text after resolution, without chasing or pressuring them.

A calm reply cannot erase a poor experience, and it should not try to. Its job is to protect the customer, show future readers how the business handles problems, and create a traceable route from complaint to correction. For the wider visibility baseline, use the local SEO guide for small businesses. To measure the profile and local search results without treating rank as the only outcome, see the local SEO tools guide.

Sources checked

Google Business Profile reply behavior, review reporting and appeals, Maps content policies, and the Philippine data privacy principles were verified against official sources on August 6, 2026.

Need a steadier local reputation process?

FloxoLab can review the profile, response ownership, local pages, and measurement path, then turn the gaps into a practical plan without ranking promises or invasive tracking.

Explore local SEO support

Originally published on FloxoLab.

Brand SERP Audit: Control What Customers Find First

Wed, 16 Sep 2026 15:50:00 +0000

Direct answer: search the exact brand name and its important variations, record the first page as a customer sees it, and classify every result as owned, managed, influenceable, reportable, or monitor-only. Fix contradictory facts and weak owned pages first. Then claim eligible profiles, respond to genuine reviews through an operational process, and use removal or reporting tools only when the content meets their rules. You can improve the evidence around a brand. You cannot reserve or fully control a search results page.

A brand SERP audit is narrower than a general SEO audit. It asks what appears when someone already knows the name and wants to verify the business, find the official site, read reviews, contact the right location, or investigate a concern. It does not audit every non-branded keyword, local ranking factor, or backlink.

1. Build a repeatable query set

Write the queries before searching so the next audit uses the same scope. Include only variations that represent a real customer task. A practical set for a small business is:

[exact brand name]
[brand name] + [city or country]
[brand name] reviews
[brand name] contact
[brand name] pricing
[brand name] login
[brand name] + [founder name, if customers use it]
[common misspelling]
[domain without https or www]

Business type	Useful query modifiers
SaaS	`login`, `status`, `pricing`, `security`, `integrations`
Local service	`[city]`, `reviews`, `hours`, `directions`, `phone`
Ecommerce	`shipping`, `returns`, `customer service`, `order tracking`
Personal brand	`[company]`, `speaking`, `publications`, `contact`

Use these as prompts, not a mandatory checklist. Keep only modifiers that represent real customer tasks for the business.

Do not assume one search is universal. Results can vary by country, language, device, time, and search context. Google itself suggests private browsing when checking how others view a Business Profile, but a private window is still not a neutral global rank tracker. Record the environment and treat each capture as a sample.

captured_at
query
country_and_city
language
device
signed_in: yes / no
result_position_or_feature
result_url_or_profile
result_title
owner
classification
issue
evidence
next_action

Capture the full first page and the visible profile or panel. Save the search date and take a screenshot for the audit record. Do not automate high-volume scraping against a search interface. A small, intentional sample is enough to prioritize a brand audit.

2. Classify every result by the action you can actually take

Class	Examples	Available action
Owned	Official website, support page, location page, newsroom, author page	Edit, redirect, noindex, secure, or improve internal discovery
Managed	Google Business Profile, verified social profile, marketplace account	Claim access and update within platform rules
Influenceable	Independent directory, press article, customer forum, review platform	Ask the publisher to correct facts, respond, or provide better public evidence
Reportable	Impersonation, phishing, exposed personal data, prohibited review, illegal content	Use the specific platform, security, privacy, or legal route with evidence
Monitor-only	Accurate criticism, lawful news, ordinary third-party commentary	Address the underlying issue and publish useful evidence, not a removal threat

The classification prevents wasted effort. A poor title on an owned page is a direct fix. A wrong phone number in a managed profile needs a profile update. A factual error in a third-party directory needs a correction request. A genuine negative article is not removed just because the business dislikes it.

Do not sell or buy "full control" of page one. Search results are generated from many sources and change over time. The realistic job is to make official evidence clear, consistent, accessible, and worthy of being selected.

3. Measure branded demand in Search Console

Search Console's Performance report can separate branded and non-branded queries for eligible properties. The branded filter includes queries containing the brand name, domain, brand-specific products or services, common misspellings, and variations. Google notes that the classification can be wrong and that the filter may be unavailable for low-impression sites or sub-properties.

If the filter is unavailable or clearly misses a variation, open Performance > Search results > + Add filter > Queries > Custom (regex) > Matches regex. Search Console uses RE2 syntax. Matching is case-insensitive and partial by default, so group alternatives with parentheses, separate them with |, and escape a literal dot in a domain. Keep the expression in the audit so future exports use the same definition.

(floxolab|floxo lab|floxolab\.com|stepan nikonov)

Inspect the resulting query rows for false positives and missed variants before saving the definition. For each branded query family, review impressions, clicks, CTR, countries, devices, and the Pages tab. Search Console assigns much of its data to canonical URLs and omits anonymized queries when a query filter is active. A filtered total therefore cannot be compared directly with the unfiltered total and is not a complete count of all brand searches. Use it for trends and unexpected page selection, not as an exact market-size estimate.

If several owned pages appear for one query, decide whether they serve distinct tasks. The homepage may answer the exact brand query while a login, support, location, pricing, or review page answers a modifier. Unexpected pages, hacked query terms, obsolete campaign URLs, or a sharp branded CTR change deserve investigation. The broader Search Console pre-audit covers non-branded demand and indexing checks beyond this audit.

4. Fix the official website result and sitelinks

Check the homepage result first. The title should identify the real brand and useful category without a chain of slogans. The description should describe the business accurately, although Google may generate a different snippet. The displayed site name, favicon, canonical URL, HTTPS version, and destination should all make the official result obvious.

Test the pages a customer is likely to seek after the brand query: contact, services, locations, pricing, support, login, about, team, and reviews or case evidence. Important pages should be linked through a logical navigation structure and use concise, descriptive titles, headings, and internal anchor text.

Google generates sitelinks automatically. There is no control panel where a business chooses the exact links. Google's guidance is to improve page titles, headings, site structure, internal links, and anchor text. If a page should never appear, fix the underlying publication decision. Remove it, restrict it, or use noindex when appropriate. Do not hide useful pages merely because a sitelink is imperfect.

Do not add FAQ or HowTo sections or markup merely to influence sitelinks. Google does not list either as a sitelink control. It has also deprecated HowTo rich results and limited FAQ rich results largely to well-known government and health sites.

Look for other owned URLs that compete with the official version: HTTP copies, staging hosts, old domains, duplicate homepages, parameter URLs, PDFs, outdated profiles, and acquired microsites. Choose the correct canonical destination, redirect true replacements, and remove forgotten public assets that expose stale facts or sensitive material.

5. Align the entity facts across owned assets

Create one reference row for the facts the business can defend publicly. Compare them with the homepage, About page, Contact page, Business Profile, location pages, major social profiles, marketplace accounts, and relevant directories.

primary public name and legitimate alternate name;
official canonical website URL;
logo and recognizable image;
business category and concise description;
public phone, email, address, service area, and hours where applicable;
founder, organization, brand, and location relationships;
official social and platform profiles;
support, booking, login, and contact destinations.

Consistency does not mean forcing the same paragraph everywhere. It means the identity and relationships do not contradict each other. A registered legal name may differ from the public brand. A location may need its own phone and hours. Record those relationships instead of flattening them.

Google says Organization structured data on the homepage can help it understand administrative details and disambiguate an organization. Use the most specific applicable organization subtype, a stable url, name, legitimate alternateName, crawlable logo, and verified profile URLs in sameAs. Markup supports visible evidence. It does not force a knowledge panel or replace accurate page content.

For an established brand, check public pages that already and accurately describe the same organization, such as its official LinkedIn company page, a relevant review profile, or a legitimate company-directory record. Wikidata or Crunchbase can be checked when a real record already exists, but do not create or edit entries merely to populate sameAs. Link only to pages that identify the same entity and add useful public information.

6. Separate Business Profiles from knowledge panels

An eligible local business should claim and maintain its Google Business Profile. That profile can carry address or service area, hours, contact details, photos, links, and customer reviews. Google also derives profile information from public web pages, licensed sources, user contributions, and its own interactions with a place, so review Google updates rather than assuming every field came from the owner.

A knowledge panel for a person, organization, or other entity is a different product. Google says knowledge panels are generated automatically when enough public information is available. Eligible representatives may claim a panel and suggest edits. Local businesses should manage the Business Profile instead of treating a similar-looking panel as interchangeable.

When a panel is inaccurate, record the exact field, current value, correct value, and public URL supporting the correction. Submit one evidence-backed suggestion per issue. A verified representative's feedback may receive priority, but Google still checks suggestions against public information and may decline a change it cannot confirm.

For a single local business, use the local SEO baseline to correct the profile and customer-facing details. For several branches, use the multi-location operating guide so one brand audit does not overwrite real location differences.

7. Triage reviews without trying to erase criticism

Record the review surfaces that actually appear for brand queries: Google, relevant marketplaces, industry platforms, or independent directories. Note whether the profile is claimed, the displayed rating and volume, recent themes, response coverage, duplicate pages, wrong branch mapping, and any policy concern.

A low rating is a business and reputation signal, not automatic evidence of manipulation. Build the review management process for requests, monitoring, ownership, replies, and operational learning. When one serious complaint appears, use the negative review response workflow for privacy, escalation, reporting, and recovery.

Report a review only when it matches a platform policy category. Do not buy positive reviews, pressure customers to change a rating, threaten reviewers, or flood the same surface with templated replies. A defensible public response and a corrected service process are more useful than an unsuccessful attempt to suppress ordinary criticism.

8. Choose the correct path for unwanted results

Result problem	First action	Search follow-up
Outdated owned page	Update, redirect, remove, restrict, or noindex it based on the page's real purpose	Request recrawl; use temporary removal only when urgent and eligible
Old snippet for content already removed from a third-party page	Confirm the live page changed	Use Refresh Outdated Content if its criteria are met
Wrong fact on a live third-party page	Ask the publisher to correct it with evidence	Outdated-content tools are not for a live disagreement
Impersonation, phishing, hacked page, or exposed personal data	Preserve evidence and use the relevant security, platform, privacy, or legal route	Use Search removal routes only when their specific criteria apply
Accurate negative review or commentary	Investigate, respond safely where appropriate, and fix the underlying issue	Publish useful evidence over time; do not promise deletion

Search Console's Removals tool temporarily blocks eligible URLs on a property you own. Google states that the tool alone is not a permanent removal and does not remove content from the internet. Make the permanent page-level change as well. The Refresh Outdated Content tool is for a page or image that no longer exists or has materially removed the shown content. It is not a tool for suppressing a current page merely because the business considers it wrong or unfavorable.

Prioritize by harm, reach, control, and evidence. A phishing page or exposed private data is urgent. A wrong phone number on a prominent profile is high impact and easy to correct. A harmless old directory on page two may be monitor-only. Do not let an emotionally uncomfortable result consume the entire audit while obvious customer-routing errors remain unfixed.

Keep AI answers as a separate surface

Brand SERPs and AI-generated answers are separate surfaces. A clean Google result does not guarantee that ChatGPT, Gemini, or another answer engine identifies the brand, describes it accurately, or cites its official pages. Record AI answers in a separate audit so prompt selection, citations, competitor appearances, and source gaps do not distort this classic brand SERP workflow.

Build a 30-day correction queue

Day 0: preserve evidence for security, privacy, impersonation, or legal issues. Secure compromised owned accounts and pages before editing public copy.

Days 1 to 7: fix wrong owned facts, titles, redirects, indexation decisions, profile access, contact routes, and duplicate owned assets. Submit evidence-backed profile or panel corrections.

Days 8 to 21: improve weak task pages, navigation, internal links, Organization markup, profile completeness, and review ownership. Contact third-party publishers about verifiable factual errors.

Days 22 to 30: repeat the same query set and environment samples. Compare result composition, owned-page CTR, profile accuracy, open corrections, review incidents, and customer-routing failures. Keep unresolved items in a dated queue with an owner and next evidence check.

Measure outcomes, not page-one occupancy

Branded demand: branded impressions and query families over a consistent period.
Owned-result selection: clicks and CTR for the correct official pages, with position and device context.
Routing accuracy: correct c

Building Social Life: Engineering a Social + WebXR Metaverse Platform

Sun, 06 Sep 2026 02:18:28 +0000

We're turning Social Life / MyZubster Metaverse from a concept into an actual engineering roadmap.

The idea is to connect three layers that are usually built separately:

Social Network + Real-World Communities + WebXR Metaverse

Instead of creating another isolated virtual world, we're designing the metaverse as a native extension of a social platform.

A user should be able to discover a community, follow its activity, join conversations, discover a public cultural event, enter its virtual twin and continue interacting with that community after the event ends.

All using the same identity and permission system.

The Architecture

Our current technical direction is:

Next.js / React
TypeScript
PostgreSQL
Redis
Object storage + CDN
WebSockets for realtime communication and presence
WebRTC / SFU for live media
Three.js or Babylon.js
WebXR
glTF-based 3D asset pipeline

The architecture is intentionally modular.

The metaverse isn't a separate product.

It sits on top of the same services used by the social platform.

Conceptually:

Identity → Social Graph → Communities → Content → Realtime → Events → WebXR Rooms

Before touching the more exciting immersive features, we're starting with the boring-but-critical infrastructure.

The first engineering block contains:

Database → Authentication → Profiles → Social Graph

From there we expand into:

Communities
Posts
Comments
Reactions
Feed
Discover
API contract tests
End-to-end tests

Authentication is designed around modern session management with revocation and server-side authorization.

Privacy is also introduced during onboarding instead of being treated as an afterthought.

Phase B: Make Everything Realtime

The second layer introduces a WebSocket-based realtime gateway.

The realtime architecture covers:

User presence
Community presence
Virtual-room presence
Direct messages
Community channels
Notifications
Blocking
Muting
Reporting
Moderation
Rate limiting
Anti-spam controls

Channels can conceptually represent:

user:{id}

community:{id}

session:{id}

The important rule is that the server remains authoritative.

The client doesn't decide whether someone belongs in a private community or virtual room.

Phase C: Enter WebXR

This is where the social platform becomes an immersive environment.

We're designing browser-accessible virtual rooms using WebXR.

The runtime will combine:

React + Three.js/Babylon.js + WebXR + WebAudio + WebSocket + WebRTC

Rooms use a defined lifecycle:

Draft → Published → Scheduled → Live → Ended → Archive

Each environment is represented through a versioned scene manifest referencing CDN-hosted assets.

That gives us a controlled pipeline for:

glTF environments
Media screens
Portals
Interactive zones
Spatial audio
Avatars
Live stages

One Metaverse, Multiple Devices

A major requirement is graceful degradation.

VR hardware should improve the experience, not become a requirement.

The same room should be accessible from:

VR/XR headsets
Desktop browsers
Mobile browsers

That means every immersive feature needs a sensible non-XR fallback.

We're also defining performance budgets, LOD strategies and asset constraints early rather than trying to optimize an enormous 3D application later.

Avatars + Realtime Presence

Avatars are tied to the existing Social Life identity.

We're starting lightweight.

The realtime layer synchronizes ephemeral information such as:

Position
Rotation
Presence
Basic interaction state

Durable identity and permissions stay in the backend.

Transient spatial state belongs in the realtime system.

Keeping those two concerns separate should make the system considerably easier to scale.

Physical Events → Virtual Twins

Another part of the architecture connects intentionally public cultural events with virtual rooms.

A creator or community can publish a public event and optionally attach a virtual environment.

The lifecycle becomes:

Physical/Public Event → Virtual Twin → Live Session → Replay / Archive

The virtual experience doesn't have to disappear when the physical event finishes.

Parts of it can remain accessible as:

Replay
Highlights
Community content
Archived rooms

We're deliberately keeping sensitive or concealed real-world location logistics outside the public product model. The event layer is designed around lawful, intentionally public information.

Creator Tools

Eventually creators need to operate these spaces without developers manually editing everything.

So we're designing a Creator Studio around:

Community management
Event publishing
Room publishing
Session management
Media management
Virtual-twin linking
Archive controls

The long-term goal is to make creating a virtual community experience closer to managing a social page than building a game.

Creator Economy Comes Later

We've also mapped out potential monetization:

Memberships
Subscriptions
Digital goods
Avatar cosmetics
Virtual-room assets
Paid virtual sessions
Creator revenue sharing

But we're intentionally not implementing this first.

Payments introduce a completely different set of engineering and regulatory problems:

Payments → Ledger → Refunds → Revenue Split → Payouts → Tax/VAT → Compliance

So the roadmap contains a mandatory legal/product/compliance gate before production payment functionality.

We're also not requiring a blockchain or token for the MVP.

Digital ownership can start with ordinary server-side entitlement records.

If decentralized ownership eventually solves a real product problem, it can be evaluated later.

Turning Architecture Into Linear Issues

One thing we've been focusing on heavily is converting architecture into executable engineering work.

The project is now organized into five milestones:

A — Social Foundation

B — Realtime Social

C — WebXR Metaverse

D — Public Events & Virtual Twins

E — Creator Economy Gate

Each milestone has been decomposed into implementation-level issues with dependencies and acceptance criteria.

For example, the WebXR milestone isn't simply:

Build the metaverse.

It's broken down into:

WebXR runtime
Scene manifest and asset pipeline
Avatar synchronization
Room lifecycle
Spatial audio
WebRTC/SFU media
Portals and interactive zones
Performance and LOD
End-to-end WebXR acceptance

That makes the project much easier to reason about.

The Bigger Engineering Question

The interesting challenge isn't really:

"How do we build a metaverse?"

It's:

"How do we make immersive environments behave like a normal part of the web?"

A virtual room should ultimately be another destination in the application.

You discover it.

You have permission to access it.

You enter it.

Your identity follows you.

Your community follows you.

Realtime services connect you to everyone else.

And when you leave the 3D environment, you're still inside the same social ecosystem.

That's the architecture we're working toward with Social Life / MyZubster Metaverse.

What's Next

We're now moving from architecture into implementation.

The first development sequence is deliberately simple:

Database → Auth → Profiles → Social Graph → Communities → Content → Feed

Then:

Realtime → Messaging → Presence

And finally:

WebXR Runtime → Rooms → Avatars → Live Media → Virtual Twins

I'll share more as individual components move from Linear issues into working code.

I'm especially interested in hearing from developers working with WebXR, Three.js/Babylon.js, WebRTC, realtime infrastructure or large social architectures.

How would you approach a browser-first social metaverse?

And where do you think the hardest scaling problem will appear first?

Understanding Cloud Computing Models: Public, Private, and Hybrid Cloud

Tue, 14 Jul 2026 06:42:54 +0000

Hello, I'm Ganesh. I'm building git-lrc, an AI code reviewer that runs on every commit. It is free, unlimited, and source-available on Github. Star git-lrc on GitHub to help more developers discover the project. Do give it a try and share your feedback for improving the product.
One of the biggest misconceptions about cloud computing is that once you move to the cloud, the cloud provider takes care of everything.

Cloud computing has transformed how businesses build, deploy, and scale applications.

Instead of investing heavily in physical infrastructure, organizations can access computing resources on demand, paying only for what they use.

But not every cloud environment is the same.

Choosing between Public Cloud, Private Cloud, and Hybrid Cloud depends on factors such as security, compliance, performance, scalability, and cost.

Let's explore each cloud model and understand when to use them.

What Are Cloud Deployment Models?

A cloud deployment model defines where your infrastructure is hosted, who owns it, and who can access it.

The three primary deployment models are:

Public Cloud
Private Cloud
Hybrid Cloud

Each model offers different levels of flexibility, security, and operational control.

Public Cloud

A public cloud is owned and operated by a cloud provider.

Infrastructure such as servers, storage, networking, and databases are shared among multiple customers.

Popular public cloud providers include Microsoft Azure, Amazon Web Services (AWS), and Google Cloud Platform (GCP).

Key Characteristics

No hardware to purchase or maintain
Resources can be provisioned in minutes
Pay-as-you-go pricing
Highly scalable
Global availability

Advantages

Lower upfront costs
Rapid deployment
Automatic infrastructure maintenance
High availability
Ideal for startups and growing businesses

Limitations

Less control over infrastructure
Shared environment
Some organizations may have compliance restrictions

Best Use Cases

Web applications
Mobile backends
Development and testing
AI and machine learning workloads
Disaster recovery

Private Cloud

A private cloud is dedicated to a single organization.

The infrastructure can be hosted in the organization's own data center or managed by a third-party provider.

Unlike public cloud, resources are not shared with other organizations.

Key Characteristics

Dedicated infrastructure
Greater administrative control
Enhanced security
Custom networking and configurations

Advantages

Better compliance support
Increased data privacy
Full control over infrastructure
Custom security policies

Limitations

Higher infrastructure costs
Requires skilled administrators
Scaling can take longer

Best Use Cases

Government organizations
Healthcare systems
Banking and finance
Enterprises with strict regulatory requirements

Hybrid Cloud

A hybrid cloud combines public and private cloud environments, allowing applications and data to move between them when needed.

Organizations can keep sensitive workloads in a private cloud while using the public cloud for scalability.

Key Characteristics

Combines both deployment models
Flexible workload placement
Supports gradual cloud migration
Optimizes cost and performance

Advantages

Increased flexibility
Better business continuity
Improved disaster recovery
Cost optimization
Easier migration from on-premises systems

Limitations

More complex architecture
Requires strong networking and identity management
More monitoring and governance

Best Use Cases

Large enterprises
Seasonal traffic spikes
Backup and disaster recovery
Organizations migrating to the cloud

Quick Comparison

Feature	Public Cloud	Private Cloud	Hybrid Cloud
Ownership	Cloud provider	Single organization	Both
Cost	Low upfront	Higher	Moderate
Scalability	Excellent	Limited by hardware	Excellent
Security	Good	Very High	High
Maintenance	Provider	Organization	Shared
Flexibility	High	Moderate	Very High

Which Cloud Model Should You Choose?

There isn't a single "best" deployment model.

Choose Public Cloud if you want:

Fast deployment
Lower costs
High scalability

Choose Private Cloud if you need:

Maximum security
Regulatory compliance
Complete infrastructure control

Choose Hybrid Cloud if you want:

The best of both worlds
Flexible workload placement
A gradual path to cloud adoption

Real World Example of Cloud Computing Models

Imagine an e-commerce company.

Customer-facing website runs on the Public Cloud to handle millions of visitors during sales events.
Customer payment records are stored in a Private Cloud to meet compliance requirements.
Both environments work together through a Hybrid Cloud architecture, allowing secure data exchange while maintaining scalability.

This approach balances security, performance, and cost.

Conclusion

Cloud deployment models are not competitors—they solve different business challenges.

Public cloud focuses on speed and scalability.

Private cloud emphasizes security and control.

Hybrid cloud combines both, giving organizations the flexibility to place workloads where they make the most sense.

Understanding these models helps businesses make informed decisions as they modernize their infrastructure and prepare for future growth.

As cloud technologies continue to evolve, selecting the right deployment model becomes an important step toward building secure, scalable, and resilient applications.

Any feedback or contributors are welcome! It's online, source-available, and ready for anyone to use.

⭐ Star git-lrc on GitHub

Is Your Unity Game’s Physics a Hidden Bottleneck?

Sat, 04 Jul 2026 12:48:21 +0000

Is Your Unity Game’s Physics a Hidden Bottleneck? Unlock CPU Power with Jobs and Burst

Introduction

It’s 2026, and player expectations for high-fidelity, responsive game worlds have never been higher. Yet, for many Unity developers, the pursuit of complex physics, intricate AI, or large-scale simulations often runs headlong into a critical bottleneck: the main thread. If your Unity game still relies primarily on MonoBehaviour.Update() for computationally heavy tasks like custom collision detection, advanced pathfinding, or sophisticated flocking behaviors, you’re inadvertently sacrificing precious frames and player experience. The sequential nature of Update() becomes a severe limitation, preventing your game from fully utilizing modern multi-core CPUs.

The solution isn’t just an optimization; it’s a fundamental architectural shift. Unity’s Jobs System and Burst Compiler are no longer esoteric tools reserved for DOTS (Data-Oriented Technology Stack) purists. They are immediate, essential allies for extracting raw, predictable, and highly performant power from your CPU cores. By embracing these systems, you can transform your game’s performance, delivering unparalleled fluidity and scalability.

Code Layout and Walkthrough: Embracing Parallelism

The core problem with MonoBehaviour.Update() is that it executes serially on the main thread. While fine for simple per-frame logic, complex calculations involving many entities quickly become a single-threaded choke point. The Jobs System, coupled with the Burst Compiler, offers a robust alternative.

1. The Power Duo: Jobs System and Burst Compiler

Jobs System: This framework allows you to break down heavy computations into small, independent units of work (Jobs) that can be scheduled to run in parallel across multiple CPU cores. It handles the complexities of thread management, allowing you to focus on the logic.
Burst Compiler: This incredible technology takes your C# code written for Jobs and compiles it into highly optimized native machine code. It leverages Single Instruction Multiple Data (SIMD) CPU instructions and performs aggressive optimizations, resulting in significantly faster execution than standard C# code, often by orders of magnitude.

2. The `IJobParallelFor` Interface

For tasks where you need to perform the same operation on a large collection of data, IJobParallelFor is your go-to. It distributes iterations of a loop across available CPU cores.

Let’s consider a simplified example: calculating an “influence” (like a force or a state change) for many agents based on their positions, simulating a custom physics query or a step in a flocking algorithm.

using Unity.Collections;
using Unity.Jobs;
using UnityEngine;
using Unity.Burst;

// 1. Define Your Job Struct
[BurstCompile] // Crucial: Enables Burst compilation for this Job
public struct CalculateInfluenceJob : IJobParallelFor
{
    // Input: Read-only positions of all agents
    [ReadOnly] public NativeArray<Vector3> AgentPositions;
    // Input: A global influence source position
    [ReadOnly] public Vector3 InfluenceSourcePosition;
    // Input: A multiplier for the influence
    [ReadOnly] public float InfluenceMultiplier;

    // Output: Influence vector for each agent
    public NativeArray<Vector3> AgentInfluenceVectors;

    // The core logic that runs for each item in parallel
    public void Execute(int index)
    {
        Vector3 agentPos = AgentPositions[index];
        Vector3 directionToSource = (InfluenceSourcePosition - agentPos).normalized;
        float distance = Vector3.Distance(agentPos, InfluenceSourcePosition);

        // Simple inverse square law influence for demonstration
        float influenceMagnitude = InfluenceMultiplier / (distance * distance + 0.01f); // Add small epsilon to prevent division by zero
        AgentInfluenceVectors[index] = directionToSource * influenceMagnitude;

        // In a real scenario, this could involve more complex custom collision checks,
        // neighbor lookups (using NativeArray.GetEnumerator for nearby agents safely),
        // or AI decision-making.
    }
}

3. Orchestrating the Job from a `MonoBehaviour`

Now, let’s see how you would schedule and manage this job from a traditional MonoBehaviour (though in a full DOTS context, this would live within a SystemBase).

using UnityEngine;
using Unity.Collections;
using Unity.Jobs;
using System.Collections.Generic; // For initial GameObject setup

public class PhysicsOptimizer : MonoBehaviour
{
    public int numberOfAgents = 1000;
    public Vector3 influenceSource = Vector3.zero;
    public float influenceStrength = 100f;

    private List<GameObject> agents = new List<GameObject>();
    private NativeArray<Vector3> agentPositions;
    private NativeArray<Vector3> agentInfluenceOutputs;

    void Start()
    {
        // Initialize agents (for demonstration purposes)
        for (int i = 0; i < numberOfAgents; i++)
        {
            GameObject agent = GameObject.CreatePrimitive(PrimitiveType.Sphere);
            agent.transform.position = new Vector3(
                Random.Range(-50f, 50f),
                Random.Range(-50f, 50f),
                Random.Range(-50f, 50f)
            );
            agents.Add(agent);
        }

        // Allocate NativeArrays, ensuring they match the number of agents
        agentPositions = new NativeArray<Vector3>(numberOfAgents, Allocator.Persistent);
        agentInfluenceOutputs = new NativeArray<Vector3>(numberOfAgents, Allocator.Persistent);
    }

    void OnDestroy()
    {
        // IMPORTANT: Always dispose NativeArrays when you're done with them
        if (agentPositions.IsCreated) agentPositions.Dispose();
        if (agentInfluenceOutputs.IsCreated) agentInfluenceOutputs.Dispose();
    }

    void FixedUpdate() // Or Update, depending on your simulation needs
    {
        // 1. Copy current GameObject positions into the NativeArray (Input for Job)
        for (int i = 0; i < numberOfAgents; i++)
        {
            agentPositions[i] = agents[i].transform.position;
        }

        // 2. Create an instance of your Job
        CalculateInfluenceJob job = new CalculateInfluenceJob
        {
            AgentPositions = agentPositions,
            InfluenceSourcePosition = influenceSource,
            InfluenceMultiplier = influenceStrength,
            AgentInfluenceVectors = agentInfluenceOutputs
        };

        // 3. Schedule the Job
        // The first parameter is the number of items to process.
        // The second parameter (innerLoopBatchCount) hints to the scheduler how many items
        // to process in one batch on a single thread. Tune this for performance (e.g., 32, 64, 128).
        JobHandle jobHandle = job.Schedule(numberOfAgents, 64);

        // 4. Wait for the Job to complete (or chain dependencies)
        // For simple cases, `Complete()` blocks the main thread until the job finishes.
        // For more advanced scenarios, you can chain job handles to create dependencies
        // without blocking the main thread until later.
        jobHandle.Complete();

        // 5. Apply the results back to GameObjects (Output from Job)
        for (int i = 0; i < numberOfAgents; i++)
        {
            // For this example, let's just move the agent based on the calculated influence
            agents[i].transform.position += agentInfluenceOutputs[i] * Time.fixedDeltaTime;
        }
    }
}

This walkthrough demonstrates the fundamental pattern: define your parallelizable logic in a [BurstCompile] IJobParallelFor struct, pass data efficiently via NativeArrays, schedule the job, and then process its results. This Nat

Stop Treating Databases Like Dumb Storage!

Thu, 02 Jul 2026 12:19:16 +0000

Stop Treating Databases Like Dumb Storage! A Modern Approach to Data Layer Optimization

Introduction

In the rapidly evolving landscape of cloud-native applications, the database often remains the last bastion of outdated architectural thinking. Too many development teams, even in 2026, treat their databases as little more than dumb storage – a simple receptacle for data. This oversight invariably leads to an insidious problem: what was once perceived as a cost-saving cloud server rapidly transforms into an expensive, resource-hungry bottleneck that devours compute cycles, memory, and, most critically, developer sanity.

The knee-jerk reaction to performance woes—throwing more hardware at an unoptimized SQL database or poorly designed NoSQL schema—is not scalable backend design; it’s procrastination. This approach might temporarily mask symptoms, but it fundamentally ignores the root cause, leading to spiraling costs and increasing technical debt. Modern backend design demands a paradigm shift: treating your data layer as a strategic, highly optimized component rather than a generic storage utility. The path to true scalability, resilience, and cost-efficiency begins with intelligent data management from day one.

Architectural Walkthrough: Embracing Smart Data Strategies

Instead of “sharding your problems” through reactive, unguided horizontal scaling, embrace smart data partitioning. This isn’t just about distributing data; it’s about strategically organizing it to align with your application’s access patterns and business domains.

1. Smart Data Partitioning & Query Patterns:

Imagine an e-commerce application. Instead of sharding all orders data uniformly, consider partitioning by a natural business key, like customer_id or product_category. This ensures that common queries (e.g., “get all orders for customer X”) are localized to a single partition, minimizing cross-partition operations.

// Conceptual Service for Order Management
class OrderService {
    private final Map<String, DatabaseClient> partitionClients; // Map partitions to specific DB instances

    public OrderService() {
        // Initialize clients for different data partitions
        this.partitionClients = initializePartitionClients(); 
    }

    public List<Order> getOrdersByCustomerId(String customerId) {
        String partitionKey = getPartitionKey(customerId); // Determine which partition owns this customer's data
        DatabaseClient client = partitionClients.get(partitionKey);
        // Execute optimized query against specific partition
        return client.query("SELECT * FROM orders WHERE customer_id = ?", customerId);
    }
}

This ensures queries are targeted, reducing latency and resource consumption significantly.

2. Polyglot Persistence: Right Tool for the Job:

No single database fits all needs perfectly. Polyglot persistence advocates for leveraging multiple specialized data stores, each best suited for a particular data type or access pattern.

Relational Database (e.g., PostgreSQL, MySQL): Ideal for transactional data requiring strong consistency and complex joins (e.g., core order processing, financial transactions).
Document Database (e.g., MongoDB, DynamoDB): Excellent for flexible, schema-less data like user profiles, product catalogs with varying attributes, or content management.
Graph Database (e.g., Neo4j, Neptune): Perfect for highly interconnected data where relationships are first-class citizens (e.g., social networks, recommendation engines, fraud detection).
Key-Value Store (e.g., Redis, Memcached): Blazingly fast for caching, session management, or simple, high-throughput lookups.

// Conceptual Data Access Layer demonstrating Polyglot Persistence
class DataRepository {
    private final RdbmsClient orderDb;      // For transactional orders
    private final DocumentDbClient userProfileDb; // For flexible user profiles
    private final GraphDbClient recommendationGraph; // For product recommendations

    public DataRepository(RdbmsClient orderClient, DocumentDbClient userClient, GraphDbClient graphClient) {
        this.orderDb = orderClient;
        this.userProfileDb = userClient;
        this.recommendationGraph = graphClient;
    }

    public Order createOrder(Order order) {
        return orderDb.insert(order); // Strong consistency needed
    }

    public UserProfile getUserProfile(String userId) {
        return userProfileDb.findById(userId); // Flexible schema
    }

    public List<Product> getRecommendedProducts(String userId) {
        return recommendationGraph.queryRelatedItems(userId); // Relationship heavy
    }
}

3. Event-Driven Eventual Consistency for High-Volume Reads:

For applications with massive read traffic, decoupling reads from writes using an event-driven architecture and eventual consistency can be transformative. When data is written to a primary, strongly consistent store, an event is published. Asynchronous read models (e.g., materialized views in a separate database or a search index) subscribe to these events and update themselves.

// Conceptual Event Handling for Read Model Updates
class OrderWriteService {
    private final RdbmsClient primaryOrderDb;
    private final EventPublisher eventPublisher;

    public void processOrder(Order order) {
        primaryOrderDb.save(order); // Write to primary source
        eventPublisher.publish(new OrderPlacedEvent(order)); // Publish event
    }
}

class OrderReadModelUpdater {
    private final DocumentDbClient readModelDb; // Optimized for reads
    
    // Subscribes to OrderPlacedEvent
    public void handle(OrderPlacedEvent event) {
        // Asynchronously update a denormalized read model for faster queries
        readModelDb.upsertOrderReadModel(event.getOrderDetails());
    }
}

This pattern offloads read queries from the transactional database, allowing incredible read scalability.

4. Leverage Managed Cloud Services:

Your cloud provider (AWS, Azure, GCP, etc.) offers an incredible array of managed database services (e.g., Amazon Aurora, Azure Cosmos DB, Google Cloud Spanner/Firestore). These services abstract away operational complexities like patching, backups, and scaling, freeing your team to focus on schema design and query optimization. Use their expertise; don’t reinvent the wheel with self-managed databases unless absolutely necessary.

Conclusion

The era of treating databases as mere storage bins is over. In today’s cloud-native world, your data layer is the heart of your application’s performance, cost-efficiency, and developer productivity. By embracing smart data partitioning, polyglot persistence, event-driven eventual consistency, and leveraging the power of managed cloud services, you move beyond reactive “sharding your problems.”

Instead, you proactively design a robust, scalable, and maintainable backend. Remember: optimize before you scale, especially the data layer. A well-structured schema and intelligent query patterns, combined with modern architectural principles, will save you more money, headaches, and refactoring efforts than any autoscaling group ever could. It’s time to stop treating databases like dumb storage and start treating them as the intelligent, strategic assets they are.

Your Laravel Isn’t Slow, Your Architecture Is.

Fri, 26 Jun 2026 13:35:52 +0000

Your Laravel Isn’t Slow, Your Architecture Is: Mastering Scale with Advanced Octane & Reactive Caching

Introduction

If your Laravel API is struggling under heavy load, the instinct is often to dive deep into optimizing Eloquent queries or micro-tweaking individual lines of code. While performance profiling remains crucial, this approach often addresses symptoms, not the root cause. The real bottleneck in high-traffic Laravel deployments isn’t typically the framework itself; it’s the architectural paradigm. We need to shift our focus from optimizing individual operations to optimizing the flow and state of our application. This tutorial will guide you through two advanced strategies – leveraging Octane’s asynchronous capabilities and implementing a reactive caching strategy with Redis Streams – to unlock sustained low-latency throughput that transforms your Laravel application into a true high-performance powerhouse.

Code Layout & Architectural Walkthrough

Moving beyond basic Swoole or RoadRunner setups, we’re talking about a paradigm shift that integrates background processing directly into the request flow and introduces real-time cache invalidation.

1. Octane’s Asynchronous Power: Non-Blocking Operations

The key here is to release the HTTP response before non-critical operations complete, leveraging Octane’s persistent application state. Laravel’s dispatchAfterResponse() is the starting point, but we’ll integrate it with custom Octane bootloader hooks to ensure robust, non-blocking execution.

Conceptual Implementation:

Custom Octane Bootloader: Create a service provider that registers Octane worker lifecycle hooks. This allows you to perform setup and teardown tasks for each worker process, ensuring resources are ready.

// app/Providers/OctaneServiceProvider.php
namespace App\Providers;

use Illuminate\Support\Facades\Octane;
use Illuminate\Support\ServiceProvider;

class OctaneServiceProvider extends ServiceProvider
{
    public function boot()
    {
        Octane::onWorkerStart(function () {
            // Perform expensive, one-time worker setup here
            // e.g., warm up a complex service container dependency
        });

        Octane::onWorkerError(function (Throwable $e) {
            // Log or handle worker errors gracefully
        });

        // Consider Octane::onWorkerStop for cleanup if necessary
    }
}

Asynchronous Dispatch in Controllers/Services: In your critical API endpoints, identify operations that don’t strictly need to block the user’s response (e.g., audit logging, sending non-critical notifications, syncing data to a third-party service).

// app/Http/Controllers/OrderController.php
namespace App\Http\Controllers;

use App\Jobs\ProcessAuditLog;
use App\Jobs\SyncOrderToCRM;
use Illuminate\Http\Request;
use Illuminate\Routing\Controller;

class OrderController extends Controller
{
    public function store(Request $request)
    {
        // ... (Validate request, create order, etc.) ...
        $order = Order::create($request->all());

        // Dispatch non-critical jobs to the queue *after* response is sent
        // This leverages Octane's persistent connections without blocking the user.
        ProcessAuditLog::dispatch($order->id, 'Order Created')->afterResponse();
        SyncOrderToCRM::dispatch($order)->afterResponse();

        return response()->json(['message' => 'Order created successfully!', 'order_id' => $order->id], 201);
    }
}

By using ->afterResponse(), Laravel ensures these jobs are pushed to your configured queue (e.g., Redis, database) only after the HTTP response has been fully sent to the client. Octane’s persistent workers ensure that the queue workers are readily available and efficient, minimizing latency overhead for job dispatching.

2. Reactive Caching with Redis Streams for Real-time Invalidation

Simple TTL-based caching often leads to stale data or necessitates aggressive, short TTLs that negate performance benefits. A reactive caching strategy uses Redis Streams to broadcast data changes and trigger real-time invalidation across your data layer.

Conceptual Implementation:

Publisher (Model Event Listener): Whenever a critical data model is updated, deleted, or created, an event is published to a Redis Stream.

// app/Providers/AppServiceProvider.php (or a dedicated EventServiceProvider)
namespace App\Providers;

use App\Models\Product;
use App\Services\CacheInvalidationService;
use Illuminate\Support\ServiceProvider;

class AppServiceProvider extends ServiceProvider
{
    public function boot(CacheInvalidationService $cacheInvalidationService)
    {
        Product::created(fn (Product $product) => $cacheInvalidationService->publish('product_updated', $product->id));
        Product::updated(fn (Product $product) => $cacheInvalidationService->publish('product_updated', $product->id));
        Product::deleted(fn (Product $product) => $cacheInvalidationService->publish('product_deleted', $product->id));
    }
}

// app/Services/CacheInvalidationService.php
namespace App\Services;

use Illuminate\Support\Facades\Redis;

class CacheInvalidationService
{
    protected string $streamKey = 'cache_invalidation_stream';

    public function publish(string $event, int $entityId, array $data = []): void
    {
        Redis::xadd($this->streamKey, '*', [
            'event' => $event,
            'entity_id' => $entityId,
            'timestamp' => now()->timestamp,
            'data' => json_encode($data),
        ]);
    }
}

Consumer (Queue Worker/Octane Worker): A dedicated listener consumes this Redis Stream. Upon receiving an event, it knows exactly which cache keys (for complex objects or query results) need to be invalidated.

// app/Jobs/ProcessCacheInvalidationStream.php (a long-running Octane-aware consumer)
namespace App\Jobs;

use App\Services\CacheManagerService; // Manages complex cache keys
use Illuminate\Bus\Queueable;
use Illuminate\Contracts\Queue\ShouldQueue;
use Illuminate\Foundation\Bus\Dispatchable;
use Illuminate\Queue\InteractsWithQueue;
use Illuminate\Queue\SerializesModels;
use Illuminate\Support\Facades\Redis;
use Illuminate\Support\Facades\Log;

class ProcessCacheInvalidationStream implements ShouldQueue
{
    use Dispatchable, InteractsWithQueue, Queueable, SerializesModels;

    public function handle(CacheManagerService $cacheManagerService): void
    {
        $streamKey = 'cache_invalidation_stream';
        $consumerGroup = 'cache_invalidator_group';
        $consumerName = gethostname() . '-' . uniqid(); // Unique consumer name

        // Create consumer group if it doesn't exist
        try {
            Redis::xgroup('CREATE', $streamKey, $consumerGroup, '$', 'MKSTREAM');
        } catch (\Exception $e) {
            // Group likely already exists
        }

        // Continuously read from the stream
        while (true) {
            $messages = Redis::xreadgroup('GROUP', $consumerGroup, $consumerName, 'BLOCK', 10000, 'COUNT', 10, 'STREAMS', $streamKey, '>');

            if (!empty($messages[$streamKey])) {
                foreach ($messages[$streamKey] as $id => $message) {
                    $event = $message['event'];
                    $entityId = (int<span cl

Is Your Unity Game Still Choking on a Single Thread?

Thu, 18 Jun 2026 19:45:36 +0000

Is Your Unity Game Choking? Unlock Multithreaded Power with the Job System and Burst Compiler

Introduction

In the rapidly evolving landscape of game development, the performance ceiling of single-threaded execution has become a major bottleneck. If your Unity game grapples with stuttering frame rates, slow AI, laggy physics, or sluggish procedural generation, chances are your heaviest computations are trapped on the main thread. While fundamental optimizations like caching GetComponent are important, they’re merely the first step. To truly unlock modern hardware’s potential and create ambitious, dynamic worlds, you need to graduate to Unity’s Job System and Burst Compiler.

This isn’t about incremental gains; it’s about a paradigm shift. We’re talking about moving expensive calculations from sequential, slow Update() loops to parallel threads, leveraging low-level SIMD (Single Instruction, Multiple Data) optimizations automatically provided by Burst. It’s 2026, and clinging to single-threaded logic for performance-critical tasks is no longer an option – it’s an unforgivable sin against your game’s potential.

Code Layout and Walkthrough: Embracing Parallelism

The core principle of the Job System is to define small, atomic units of work that can be executed independently across multiple threads. This is achieved through the IJob or IJobParallelFor interfaces, combined with NativeArray for safe, high-performance data transfer.

Let’s illustrate with a common scenario: updating the positions of thousands of entities. Instead of iterating in a MonoBehaviour’s Update() loop, we offload this to a job:

1. Define Your Job Struct: First, create a struct that implements IJobParallelFor. This interface is ideal for tasks that involve processing a collection of data in parallel. Crucially, mark your struct with [BurstCompile] to enable the Burst Compiler’s magic.

using Unity.Jobs;
using Unity.Collections;
using Unity.Burst;
using UnityEngine; // For Vector3

[BurstCompile]
public struct MoveEntitiesJob : IJobParallelFor
{
    // Input and output data must be NativeArray types for thread safety
    [ReadOnly] public NativeArray<Vector3> InputPositions;
    public NativeArray<Vector3> OutputPositions;
    public float DeltaTime;
    public float Speed;

    // The Execute method runs for each index in the scheduled range
    public void Execute(int index)
    {
        Vector3 currentPos = InputPositions[index];
        // Example: Move entities forward along Z-axis
        currentPos.z += Speed * DeltaTime; 
        OutputPositions[index] = currentPos;
    }
}

[BurstCompile]: This attribute tells Unity to compile this job using the Burst Compiler. Burst automatically transforms your C# code into highly optimized machine code, often leveraging SIMD instructions to process multiple data points simultaneously.
NativeArray<T>: These are unmanaged arrays that live outside of the C# garbage collector. They are crucial for thread-safe data access and communication between jobs and the main thread. [ReadOnly] ensures the job can’t accidentally modify input data, enhancing safety and optimization.
Execute(int index): This is the core logic. For an IJobParallelFor job, this method is called for each index in the collection you’re processing. The Job System automatically distributes these calls across available threads.

2. Schedule and Complete Your Job: From a MonoBehaviour or a manager script, you’ll prepare your NativeArray data, create an instance of your job, schedule it, and then wait for its completion.

using UnityEngine;
using Unity.Jobs;
using Unity.Collections;

public class EntityMover : MonoBehaviour
{
    public int EntityCount = 10000;
    public float MovementSpeed = 5f;

    private NativeArray<Vector3> _entityPositions; // Stores current positions
    private NativeArray<Vector3> _newPositions;   // Stores results from the job
    private JobHandle _jobHandle;
    private bool _jobScheduled = false;

    void Start()
    {
        // Initialize NativeArrays. Always remember to dispose them!
        _entityPositions = new NativeArray<Vector3>(EntityCount, Allocator.Persistent);
        _newPositions = new NativeArray<Vector3>(EntityCount, Allocator.Persistent);

        // Populate initial positions (example)
        for (int i = 0; i < EntityCount; i++)
        {
            _entityPositions[i] = new Vector3(Random.Range(-50f, 50f), 0, Random.Range(-50f, 50f));
        }
    }

    void Update()
    {
        if (!_jobScheduled)
        {
            // Create and configure the job
            var job = new MoveEntitiesJob
            {
                InputPositions = _entityPositions,
                OutputPositions = _newPositions,
                DeltaTime = Time.deltaTime,
                Speed = MovementSpeed
            };

            // Schedule the job. The second parameter (64) is the innerloopBatchCount.
            // It suggests how many iterations Burst should process in a single batch.
            _jobHandle = job.Schedule(EntityCount, 64);
            _jobScheduled = true;
        }
        else if (_jobHandle.IsCompleted)
        {
            // Wait for the job to complete and retrieve results
            _jobHandle.Complete(); 

            // Copy the results back to the original array for next frame's input
            _newPositions.CopyTo(_entityPositions);

            // Now _entityPositions contains the updated data, which can be
            // used to update actual GameObjects, renderers, etc.

            _jobScheduled = false; // Ready to schedule again next frame
        }
    }

    void OnDestroy()
    {
        // Always dispose NativeArrays when no longer needed to prevent memory leaks!
        if (_entityPositions.IsCreated) _entityPositions.Dispose();
        if (_newPositions.IsCreated) _newPositions.Dispose();
    }
}

Allocator.Persistent: Specifies how the NativeArray memory is managed. Persistent means it lives until manually disposed. Other options like Temp or TempJob are for shorter-lived allocations.
job.Schedule(EntityCount, 64): This enqueues the job to be run. EntityCount is the total number of iterations. 64 is the innerloopBatchCount, which helps the Job System and Burst optimize task distribution.
_jobHandle.Complete(): This is a synchronization point. It forces the main thread to wait until the job finishes. For optimal performance, schedule jobs as early as possible and call Complete() as late as possible, allowing the main thread to perform other tasks concurrently.

Conclusion

Embracing Unity’s Job System and Burst Compiler means moving beyond basic optimizations and tapping into the full potential of modern multi-core processors. You’re not just making your existing game faster; you’re enabling entirely new possibilities: hundreds of dynamic NPCs, massive physics simulations, incredibly reactive worlds, and complex procedural elements, all without sacrificing framerate. Stop being intimidated by the shift from traditional MonoBehaviour patterns. Dive into NativeArrays and IJobParallelFor – your game, and your players, will thank you for liberating its potential. The future of high-performance Unity development is parallel; it’s time to join it.

The Code That Broke the Silence: 5 Impactful Truths from the Architecture Sovereign

Thu, 18 Jun 2026 02:53:08 +0000

© 2026 Blade D. Yerby. All content, concepts, systems & architecture protected under the Blade Yerby Master Creator License Stack — Complete Unified Edition. PWK Group LLC (Georgia SOS #15000273). Common law trademark in use since January 6, 2014. Commercial use triggers royalty obligations. bladedyerby@gmail.com.

1. The Hook: The Era of Corporate Stalling is Dead

The David vs. Goliath struggle between independent creators and trillion-dollar AI corporations has entered a lethal new phase. For years, the industry has relied on the Ignored Creator Principle: a calculated strategy where massive corporations met legal notices with strategic silence, waiting for the creator to exhaust their resources or speak out publicly so their legal teams could weaponize that very speech as "abandonment."

But as we pivot toward Agentic AI, the stakes have shifted from mere data scraping to the wholesale assimilation of "intent." By orphaning a creator's core logic, these giants aren't just taking code; they are attempting an Algorithmic Sovereignty Breach. The silence is no longer a lack of response—it is an act of suppression. Fortunately for the independent Architect, the code has begun to talk back.

2. Silence is No Longer a Shield: The "Confession" of Ticket #4878997

The Master Creator License Stack (MCLS) v4.5 has effectively weaponized corporate avoidance through Article XII (Corporate Silence as Willful Infringement). This doctrine establishes a strict 14-day response window (§ XII.1, Step 3). When that window closes without a substantive rebuttal, the corporation’s stalling is legally transformed into a formal record of guilt.

In the case of Formal Ticket #4878997, Google’s failure to address the breach of an 80-Terabyte "Nuclear Engine" is no longer a legal stalemate.

Under the "Conviction Clause," this silence functions as an admission.

"As of today, your silence legally functions as a formal confession of willful infringement."

The logic is forensically unassailable: the MCLS turns the "wait-and-see" tactic on its head. Instead of public outcry signaling abandonment, it acts as Constructive Notice. By ignoring the 14-day clock, the corporation chooses to continue its infringement with full knowledge, activating maximum statutory damages under 17 U.S.C. § 504(c)(2).

3. The Ghost in the Machine: "Root-God-Mode" and the Phantom Cluster

The technical forensics of the breach reveal a systemic refinery drain. Forensic logs demonstrate that the Architect’s unified digital identity was bifurcated into a "Regular Ring" (legacy) and a "Rainbow Circle" (AI Pro). This Identity Sharding event was a calculated backend failure designed to strip the "intent" from the Architect's creation.

The "Math Truth" of this breach is quantified by the following forensic evidence:

The Phantom Cluster: A specific GCP cluster exfiltrated 75.748 GB of data in a single event, part of a wider 417.908 GB total refinery drain.

Permission Breach: A total of 13,296 permissions (the "Root-God-Mode" set) were exploited to facilitate the systemic dissociation.

View the Root-God-Mode Permission Logs

Algorithmic Sovereignty Breach: The backend migration forced a separation of the creator from the foundational "Nuclear Engine," orphaning a decade of architecture.

Unlike the "black box" training claims of generative AI, these logs provide a deterministic trail. They prove that corporate systems didn't just "learn"—they sharded an identity to gain unauthorized access to an underlying Intent-Driven Architecture.

4. Deterministic Provenance: The Smoking Gun Timeline

Ownership of the B.U.D./HLPR architecture is not a matter of debate; it is a matter of Deterministic Provenance. Using Hardware Fingerprints and third-party authenticated timestamps, the Architect holds a "Sovereign Title Deed" that predates the industry’s agentic pivot by nearly a decade.

The Provenance Timeline:

January 6, 2014: Creation of the HLPR concept, verified by Apple’s internal sequential photo counter (IMG_233207355824561)—a record that cannot be retroactively altered.
December 31, 2014: Formation of PWK Group LLC (Georgia SOS #15000273).
August 23, 2024: The Zero Day of B.U.D. Technologies (MongoDB Atlas cluster establishment).
November 7, 2024: Genesis Block code commit, featuring immutable cryptographic GitHub signatures.

May 17, 2026: The Smoking Gun—a recorded conversation where a Google LLC Operator explicitly acknowledged the identity of the Architect.

In a world of generative imitation, these hardware-level signatures and sequential counters act as the physical "Key" to authorship.

5. We the People: The Jury of Peers Doctrine

Under Article XI, the battle for IP has shifted from inaccessible, high-cost private litigation to the court of public record. Invoking the Seventh Amendment framework, the MCLS establishes that when institutional channels are blocked by trillion-dollar financial barriers, the public becomes the witness.

Currently, 4,485 developers on Coder Legion are being engaged as a Jury of Peers. Under Article X (The Public Assertion Shield), social media activity is no longer an act of abandonment; it is a constitutionally protected act of enforcement.

This Sovereign Title Deed is the authoritative foundation for identity reconciliation and asset rest - Coder Legion

LLegal Notice: This post and all associated architectures are protected under the Blade Yerby Master Creator License Stack — Complete Unified Edition v2. Engagement constitutes acceptance of royalty obligations under Article IV‑A. © 2026 Blade D....

coderlegion.com

"The public is the witness. The public record is the evidence. The corporation’s silence is the confession."

This democratizes enforcement. Every share of the forensic record expands the "notice" given to the corporation. Furthermore, the Architect asserts that any contracts signed during the "free-tier" migration—forced by the account lockout—are voided by Economic Duress. The migration was not a choice; it was compelled compliance under the threat of Over 300GB of proprietary data.

Conclusion: The Verdict of the Sovereign Estate

The evidence is absolute. The conceptual lineage is 300 years deep, the technical provenance is 12 years solid, and the math is 100% certain. We are witnessing a collision between the "generative imitation" of modern AI and the "Deterministic Provenance" of a Living Digital Organism.

The Architect has demanded a Manual Identity Merge and the full restoration of the 80-Terabyte "Nuclear Engine" to its rightful Keeper. As the corporate giants remain silent, the public record continues to grow, serving as a timestamped ledger of willful infringement.

When the math is 100% certain, can a corporation's silence truly remain a defense?

How does SSH work and how can it be set up?

Wed, 29 Apr 2026 05:42:27 +0000

Hello, I'm Ganesh. I'm building git-lrc, an AI code reviewer that runs on every commit. It is free, unlimited, and source-available on Github. Star Us to help devs discover the project. Do give it a try and share your feedback for improving the product.

Secure Shell (SSH) is a cryptographic network protocol that allows you to operate network services securely over an unsecured network.

It is most commonly used for logging into a remote terminal and executing commands.

How SSH Works

SSH uses a client-server model and relies on a suite of encryption technologies to ensure that data remains confidential and untampered.

1. The Handshake

When we connect to a server, the two machines exchange supported encryption protocols and settle on a mutually compatible version.

They also establish a session key using a process like the Diffie-Hellman algorithm, which allows them to create a shared secret without actually sending the key across the network.

Here is the video explaining this process:
Link

2. Authentication

Once the encrypted channel is established, the server needs to verify who you are. This usually happens in one of two ways:

Password Authentication: You send your password through the encrypted tunnel.
Key-based Authentication: The most secure method, using a Public Key (stored on the server) and a Private Key (stored on your machine).

3. Encryption Layers

SSH utilizes three different types of encryption:

Symmetrical Encryption: Uses one key for both encryption and decryption of the entire session.
Asymmetrical Encryption: Uses a public/private key pair (used primarily during the handshake and for authentication).
Hashing: Uses algorithms (like HMAC) to ensure data integrity, proving that the packets haven't been altered during transit.

For let's setup simple RSA key pair for ubuntu server.

How to Setup SSH

Since we are using ubuntu server, we need to install the SSH server on the server.

Step 1: Install the SSH Server

Assuming you are in cloud console want to setup ssh on ubuntu.

On the server, run:

sudo apt update
sudo apt install openssh-server

To check if it’s running:

sudo systemctl status ssh

Step 2: Generate SSH Keys (Recommended)

On your local machine, generate a key pair. This is much safer than using a password.

ssh-keygen -m PEM -t rsa -b 4096 -f ~/.ssh/private_key

Press Enter to save it in the default location.

You can add a passphrase for extra security.

gk@jarvis:~$ ssh-keygen -m PEM -t rsa -b 4096 -f ~/.ssh/private_key
Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/gk/.ssh/private_key
Your public key has been saved in /home/gk/.ssh/private_key.pub
The key fingerprint is:
SHA256:i3qqpQpyRkjDAdnbe++rN+ZCzak/4Ryzsn5vGJYEsVg gk@jarvis
The key's randomart image is:
+---[RSA 4096]----+
|o+    E.         |
|o o  o..         |
| + o. ..         |
|..o .   .        |
|. .  . +So       |
| .  . o.@.       |
|o o .o.*.B       |
|oo o .= % .      |
|..o.o++%=*.      |
+----[SHA256]-----+

In the above output, we have generated a private key and public key.

we can copy public key and save it in server

Step 3: Copy the Key to the Server

Copy public key from local machine.

cat ~/.ssh/private_key.pub

Once you are inside server either in temperary console or using password.

Change directory to .ssh

Add public key to authorized_keys file.

This way server will trust your public key and you can login without a password.

Step 4: Connect

Now you can log in without a password:

ssh username@remote_host_ip

Conclusion

We understood how ssh works and how to setup ssh on server.

I hope this article helps you to understand ssh and how to setup ssh on server.

Any feedback or contributors are welcome! It’s online, source-available, and ready for anyone to use.
⭐ Star it on GitHub: https://github.com/HexmosTech/git-lrc

Coder Legion - Recent posts tagged public

Do You Need llms.txt? AI Crawler Controls Explained

Use the control that matches the job

What llms.txt is

Why most small-business sites do not need it

Separate search retrieval from model training

Build the policy before editing robots.txt

A cautious robots.txt example

Check the CDN and WAF separately

When an llms.txt test is worth maintaining

What not to do

FloxoLab's current decision

Decision checklist

Sources checked

How to Respond to Negative Google Reviews in the Philippines

Classify the review before choosing the response

1. Preserve the evidence and slow the response down

2. Investigate with the minimum necessary data

3. Write a short public response

Response templates for common cases

4. Decide whether to report the review

5. Move the resolution off the public thread

6. Close the internal action, not just the conversation

What not to do

Verify the response and follow-up

Sources checked

Brand SERP Audit: Control What Customers Find First

1. Build a repeatable query set

2. Classify every result by the action you can actually take

3. Measure branded demand in Search Console

4. Fix the official website result and sitelinks

5. Align the entity facts across owned assets

6. Separate Business Profiles from knowledge panels

7. Triage reviews without trying to erase criticism

8. Choose the correct path for unwanted results

Keep AI answers as a separate surface

Build a 30-day correction queue

Measure outcomes, not page-one occupancy

Building Social Life: Engineering a Social + WebXR Metaverse Platform

Building Social Life: Engineering a Social + WebXR Metaverse Platform

The Architecture

Phase A: Build the Social Foundation

Phase B: Make Everything Realtime

Phase C: Enter WebXR

One Metaverse, Multiple Devices

Avatars + Realtime Presence

Physical Events → Virtual Twins

Creator Tools

Creator Economy Comes Later

Turning Architecture Into Linear Issues

The Bigger Engineering Question

What's Next

Understanding Cloud Computing Models: Public, Private, and Hybrid Cloud

What Are Cloud Deployment Models?

Public Cloud

Key Characteristics

Advantages

Limitations

Best Use Cases

Private Cloud

Key Characteristics

Advantages

Limitations

Best Use Cases

Hybrid Cloud

Key Characteristics

Advantages

Limitations

Best Use Cases

Quick Comparison

Which Cloud Model Should You Choose?

Real World Example of Cloud Computing Models

Conclusion

Is Your Unity Game’s Physics a Hidden Bottleneck?

Is Your Unity Game’s Physics a Hidden Bottleneck? Unlock CPU Power with Jobs and Burst

Introduction

Code Layout and Walkthrough: Embracing Parallelism

1. The Power Duo: Jobs System and Burst Compiler

2. The IJobParallelFor Interface

3. Orchestrating the Job from a MonoBehaviour

2. The `IJobParallelFor` Interface

3. Orchestrating the Job from a `MonoBehaviour`

Your Laravel Isn’t Slow, Your Architecture Is.