|
|
|
||||
|
Welcome to the GoFuckYourself.com - Adult Webmaster Forum forums. You are currently viewing our boards as a guest which gives you limited access to view most discussions and access our other features. By joining our free community you will have access to post topics, communicate privately with other members (PM), respond to polls, upload content and access many other special features. Registration is fast, simple and absolutely free so please, join our community today! If you have any problems with the registration process or your account login, please contact us. |
![]() |
|
|||||||
| Discuss what's fucking going on, and which programs are best and worst. One-time "program" announcements from "established" webmasters are allowed. |
|
|
Thread Tools |
|
|
#101 |
|
The FraudBuster
Industry Role:
Join Date: Aug 2024
Location: Brantford, Ontario
Posts: 579
|
100 Ai Agents
I'm happy to discuss this stuff with anyone interested except for that fucking idiot 2MuchMark. If you need a project done, hit me up at WebIgniter.com
__________________
The Brantford Insider |
|
|
|
|
|
#102 | ||
|
Videochat Solutions
Industry Role:
Join Date: Aug 2004
Location: Canada
Posts: 49,817
|
Quote:
In this post https://gfy.com/23417110-post18.html (Post #18), when asked "How do you monetize the site?", you listed premium listings, ads, email signups, and other traditional directory monetization. You said "how many ways can you monetize a wordpress site?" - not "it's a demo." In this post https://gfy.com/23417008-post1.html (#1), you said it "makes money and business" - not "generates leads for my services." You only started calling it a "lead magnet" after I asked about your rankings being for zero-volume branded keywords. If it was always meant as a demo, then why: 1. Show Search Console screenshots claiming "top 5's" and "150 ranked top 10"? 2. Claim it "outranks TripAdvisor for many local searches"? 3. Refuse to show traffic data when asked? 4. Explain traditional monetization methods instead of saying "it's a demo"? The ranking screenshots show restaurant name searches with zero volume. That's not SEO success for either purpose Mindi not for making money, and not for demonstrating your skills to potential clients who know SEO (I have learned alot from Rob...) A real SEO demo would show rankings for competitive discovery keywords, or you would have just said from the start "this is a demo of my automation skills, not an SEO case study." Quote:
Some advice:Focus on your automation stuff. It's good. Don't try to fool Google, it won't work.
__________________
|
||
|
|
|
|
|
#103 |
|
Videochat Solutions
Industry Role:
Join Date: Aug 2004
Location: Canada
Posts: 49,817
|
__________________
|
|
|
|
|
|
#104 |
|
The FraudBuster
Industry Role:
Join Date: Aug 2024
Location: Brantford, Ontario
Posts: 579
|
Mark - You're moving goalposts again. You can't even keep your shit straight.
Your new attack: "Your rankings are for branded keywords, that's not impressive SEO" No shit! It's 4 days old. The test model is barely 3 weeks old. I never claimed to be ranking for "best restaurants in Montreal" yet. That takes months. Don't you fucking know ANYTHING about SEO? But here's what IS working: Business owners Google themselves → find my listing → contact me Multiple inquiries in 3 weeks. Multiple inquires from this thread alone. MANY MORE from the other places I have posted this same exact thing but for other cities. I do not just hang out on GFY Four signed projects (not sharing any details with idiots like you) and several that I've walked away from. I can fucking do that You said: "You asked Claude if it would work and Claude said NO" That's a lie. Show me where Claude said it wouldn't work. You can't, because it didn't happen. The automation works. The business model works. The only thing that's failing is your attempt to discredit it. You are not interested, move on. You're just trying to attack my business AGAIN. I've never said this was for sale, it is NOT FOR SALE. Now go ahead and call me a fucking scammer again like your employee likes to do. Where have I ever scammed ANYONE here in over 20 fucking years? I've told you many times, I will not do ANY BUSINESS with YOU or anyone I feel has your fucking odor on them. Stop making shit up. Go back to your little queer threesome with Legacy and Scrapper ![]() While you're sitting here being Legacy and Scrapper's flying monkey, I'm putting out site after site after site. You have no fucking idea how I can scale things ![]()
__________________
The Brantford Insider |
|
|
|
|
|
#105 |
|
The FraudBuster
Industry Role:
Join Date: Aug 2024
Location: Brantford, Ontario
Posts: 579
|
One last thing:
Some people on this forum seem more interested in tearing down other people's success than building their own. I'm not here to argue with trolls. I'm here to build assets and help businesses. If you want something built - WebIgniter.com If you want to argue - find someone else. I've got work to do.
__________________
The Brantford Insider |
|
|
|
|
|
#106 | |
|
Confirmed User
Industry Role:
Join Date: Aug 2024
Posts: 20
|
Quote:
|
|
|
|
|
|
|
#107 | |
|
The FraudBuster
Industry Role:
Join Date: Aug 2024
Location: Brantford, Ontario
Posts: 579
|
Quote:
This morning, I built a new auto approval process. I still have it set to manual admin approval though for testing. Your timing with this question was impeccable This is how I plan my agent: Business Claim Verification System - Brantford Insider Overview Build a system where business owners can claim their listings. After verification (phone or email) and admin approval, they receive a "Verified Owner" badge on their listing. User Flow Business Owner Flow 1. Owner visits business listing page 2. Clicks "Claim This Business" button 3. Fills out claim form (name, email, phone, role at business) 4. Chooses verification method: Phone or Email 5. Phone: Receives verification code, calls/visits site to enter it 6. Email: Receives magic link, clicks to verify 7. Claim goes to admin queue for final approval 8. Once approved, listing shows "Verified Owner" badge Admin Flow 1. New claims appear in WP Admin → Business Claims 2. Admin sees: business name, claimant info, verification status 3. Admin can: Approve, Reject (with reason), Request more info 4. Approved claims add verified badge to listing --- Technical Implementation Phase 1: Data Structure New ACF Fields (add to includes/acf-fields.php) // Business Claim Status Group - claim_status: select (unclaimed, pending, verified, rejected) - claim_verified_date: date - claim_owner_name: text - claim_owner_email: email - claim_verification_method: select (phone, email) New Database Table: wp_business_claims CREATE TABLE wp_business_claims ( id BIGINT AUTO_INCREMENT PRIMARY KEY, business_id BIGINT NOT NULL, claimant_name VARCHAR(255), claimant_email VARCHAR(255), claimant_phone VARCHAR(50), claimant_role VARCHAR(100), verification_method ENUM('phone', 'email'), verification_code VARCHAR(20), verification_code_expires DATETIME, email_verified TINYINT DEFAULT 0, phone_verified TINYINT DEFAULT 0, status ENUM('pending', 'email_sent', 'code_sent', 'verified', 'approved', 'rejected') DEFAULT 'pending', rejection_reason TEXT, admin_notes TEXT, created_at DATETIME DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME ON UPDATE CURRENT_TIMESTAMP, INDEX (business_id), INDEX (status) ); Phase 2: Backend Infrastructure New File: includes/claim-verification.php - cbd_create_claims_table() - Creates DB table on activation - cbd_generate_verification_code() - 6-digit code generator - cbd_send_verification_email() - Magic link email - cbd_verify_email_token() - Validates email links - cbd_verify_phone_code() - Validates phone codes - cbd_submit_claim() - AJAX handler for claim form - cbd_get_claim_status() - Check if business is claimed New File: includes/claim-admin.php - Admin menu page: "Business Claims" - List table showing all claims with filters - Approve/Reject actions with AJAX - Email notifications to claimant on status change Phase 3: Frontend Templates New Template: templates/page-claim-business.php - Claim form with fields: - Business selector (if coming from generic page) - Your Name - Your Email - Your Phone - Your Role (Owner, Manager, Marketing, etc.) - Verification Method (Phone / Email radio) - Terms acceptance checkbox - AJAX submission - Success/error messaging Modify: templates/single-business-restaurant.php (and other single templates) - Add "Claim This Business" button (if unclaimed) - Add "Verified Owner" badge (if claimed & approved) - Button links to /claim-business/?business_id=XXX New Template Section: Verification Code Entry - Simple form to enter 6-digit code - Or: Email link lands on verification confirmation page Phase 4: Email Templates Verification Email Subject: Verify your ownership of [Business Name] on Brantford Insider Hi [Name], You requested to claim [Business Name] on Brantford Insider. Click here to verify your email: [MAGIC LINK] This link expires in 24 hours. If you didn't request this, ignore this email. Phone Verification Instructions Subject: Your verification code for [Business Name] Hi [Name], Your verification code is: [6-DIGIT CODE] Enter this code at: [VERIFICATION URL] This code expires in 1 hour. Claim Approved Email Subject: Your claim for [Business Name] has been approved! Hi [Name], Great news! Your claim for [Business Name] on Brantford Insider has been approved. Your listing now shows a "Verified Owner" badge. To request changes to your listing, contact us at [email]. --- Files to Create/Modify NEW FILES 1. custom-business-directory/includes/claim-verification.php - Core claim logic 2. custom-business-directory/includes/claim-admin.php - Admin interface 3. custom-business-directory/templates/page-claim-business.php - Claim form page 4. custom-business-directory/assets/css/claim-form.css - Claim form styles 5. custom-business-directory/assets/js/claim-form.js - AJAX handling MODIFY FILES 1. custom-business-directory/custom-business-directory.php - Include new files, register activation hook 2. custom-business-directory/includes/acf-fields.php - Add claim status fields 3. custom-business-directory/templates/single-business-restaurant.php - Add claim button & badge 4. custom-business-directory/templates/single-business-service.php - Add claim button & badge 5. custom-business-directory/templates/single-business-retail.php - Add claim button & badge 6. custom-business-directory/templates/single-business.php - Add claim button & badge 7. custom-business-directory/assets/css/style.css - Badge styles --- Implementation Order 1. Database & ACF Fields - Create table, add fields 2. Claim Form Page - Frontend form that submits claims 3. Email/Phone Verification - Code generation and validation 4. Admin Interface - View and manage claims 5. Badge Display - Show verified badge on listings 6. Claim Button - Add to all single business templates 7. Testing - Full flow testing on Brantford site --- Security Considerations - Rate limit claim submissions (1 per business per email per 24h) - Verification codes expire (1h phone, 24h email) - Sanitize all inputs - Nonce verification on all forms - Email verification tokens are one-time use - Admin-only approval (no auto-approve) --- Badge Design .verified-owner-badge { display: inline-flex; align-items: center; background: linear-gradient(135deg, #10B981 0%, #059669 100%); color: white; padding: 6px 12px; border-radius: 20px; font-size: 13px; font-weight: 600; } .verified-owner-badge::before { content: "✓"; margin-right: 6px; } --- Estimated Components | Component | Complexity | Priority | |--------------------------|------------|----------| | Database table | Low | P0 | | ACF fields | Low | P0 | | Claim form page | Medium | P0 | | Email verification | Medium | P0 | | Phone code verification | Low | P0 | | Admin claims list | Medium | P0 | | Approve/Reject actions | Low | P0 | | Badge on listings | Low | P1 | | Claim button on listings | Low | P1 | | Email templates | Low | P1 | --- Test Plan 1. Submit claim for unclaimed business 2. Choose email verification → receive email → click link 3. Verify claim shows in admin as "verified, pending approval" 4. Admin approves → badge appears on listing 5. Submit another claim for same business → should show "already claimed" 6. Test phone verification flow 7. Test rejection flow with reason 8. Test expired verification codes The system is being built right at this very moment. ![]()
__________________
The Brantford Insider |
|
|
|
|
|
|
#108 |
|
Confirmed User
Industry Role:
Join Date: Aug 2024
Posts: 20
|
Thanks for the writeup. I was curious if the number had to match the one on their yelp/google listing or email had to match although they don't usually display emails. So not just anyone could verify with any phone or email. Like a way to make sure they are who they say they are.
|
|
|
|
|
|
#109 |
|
The FraudBuster
Industry Role:
Join Date: Aug 2024
Location: Brantford, Ontario
Posts: 579
|
The verification code confirms they have access to the contact info they provide - but that's just step one. Right now, every claim requires manual admin approval before the verified badge appears.
When a claim comes in, I review it before approving: - Cross-reference the claimant's info with what's on the listing - Check their email domain matches the business website - Call the business directly if anything looks off - Google the person + business name So even if someone tried to claim a business with random contact info, they'd get flagged at the admin review stage. The automated verification just filters out spam and confirms they're a real person - the human review is where I actually verify legitimacy, at least for now. I'm also looking at adding domain-based email verification (requiring @businessdomain.com emails) as an additional layer.
__________________
The Brantford Insider |
|
|
|
|
|
#110 |
|
👏 REVOLUTIONARY 👏
Industry Role:
Join Date: Oct 2012
Posts: 2,412
|
That seems like a lot of implementation details. Have you explored contextualizing your codebase and then writing more high level things?
For example, I have an AI tool I'm working on that basically just chews through your whole codebase and pulls out all the details it can that are relevant, basically generates a whole readme document that explains everything about the app, architectural decisions, coding patterns, tools used, etc. Then I write high level epics that are broken down into tasks that look sorta like this, which is a real ticket I have for a task my agent implemented recently: Code:
## Summary / Purpose Extend the existing SES webhook ingestion system so it can process additional SES event types using the **same unified ingestion pipeline** already used for current SES events. The system does **not** distinguish between “inbound” or “outbound” events — all SES events flow through a single lifecycle: 1. Parse the JSON payload 2. Determine the SES event type 3. Ignore unsupported events 4. Validate supported events 5. Normalize supported events into the unified schema 6. Emit internal events 7. Respond to SES This task only adds new SES event types to that pipeline. No new webhook, no new lifecycle, and no additional architectural concepts are introduced. --- ## Supported SES Event Types to Add Extend the current allowlist by adding support for the following SES event types: - `Send` - `Delivery` - `Bounce` - `Complaint` - `DeliveryDelay` All other SES event types remain **ignored**, logged at debug level, and acknowledged with success. --- ## Validation Requirements (Supported Event Types Only) For events in the allowlist above, validation rules must match the existing SES ingestion model: - JSON must parse correctly. - `eventType` or `notificationType` must be present. - A `mail` object must exist and include: - `messageId` - `timestamp` - `source` - `destination[]` (non-empty) - The corresponding SES event-specific object must exist: - `Send` → `send` - `Delivery` → `delivery` - `Bounce` → `bounce` - `Complaint` → `complaint` - `DeliveryDelay` → `deliveryDelay` Failures in validation: - Must be logged at **error** level with a reason and message ID (if available). - Must return a **non-success** response to SES. - Must stop all processing and emit no internal events. Unsupported events do **not** undergo validation. --- ## Normalization Requirements For supported and validated SES events, normalize into the existing unified internal schema: ### Core Message Fields - `message_id` - `from_address` - `recipients` - `sent_at` (parsed into a standardized timestamp format) - `tags` (preserved exactly as SES provides them) ### Event Metadata - `id` (feedback ID when present) - `type` (one of: `send`, `delivery`, `bounce`, `complaint`, `delay`) - `timestamp` (event-specific timestamp, parsed into standardized timestamp format) ### Optional Event-Type Blocks Depending on `type`, include one of: - `bounce` - `complaint` - `delivery` - `delay` Each block includes its expected fields exactly as defined in the normalized schema. Normalization must be SES-agnostic — no SES field names should leak into the internal event shape. --- ## Internal Event Emission Emit exactly one internal event for each normalized SES event: - `type = "send"` → `EmailSent` - `type = "delivery"` → `EmailDelivered` - `type = "bounce"` → `EmailBounced` - `type = "complaint"` → `EmailComplaint` - `type = "delay"` → `EmailDelayed` Internal events must include **only** the normalized data — never SES raw JSON. If emission fails for any reason: - Log the error. - Return a **non-success** response to SES. - Stop further processing. --- ## Logging & Response Behavior Re-use the same semantics already implemented for SES ingestion: ### Debug Logs - Unsupported SES event types that are ignored. ### Error Logs - JSON parsing failures. - Validation failures for supported events. - Internal event emission failures. ### Response Rules Return **success (2xx)** only when: - JSON parsed successfully. - All supported events validated successfully. - All supported events normalized successfully. - All supported events emitted successfully. - Unsupported events were ignored without issues. Return **non-success** otherwise. --- ## Out of Scope - Any business logic reacting to these events. - Storage or indexing of normalized event data. - UI or reporting updates. - Changes to the inbound SES behavior beyond sharing the unified pipeline. - SES configuration, SNS topic setup, DNS, or identity management. In my experience this has allowed me to not write so much implementation details basically coding in psuedo code and write more high level stuff and then let the agent infer how to implement it and the patterns and architectural decisions from my agents.md file that contains all that context.
__________________
|
|
|
|
|
|
#111 | |
|
Videochat Solutions
Industry Role:
Join Date: Aug 2004
Location: Canada
Posts: 49,817
|
Quote:
__________________
|
|
|
|
|
|
|
#112 | |
|
The FraudBuster
Industry Role:
Join Date: Aug 2024
Location: Brantford, Ontario
Posts: 579
|
Quote:
This is eye opening. I could apply that to my process. I could build 50 with the same pattern. That's a little overkill. I like it.
__________________
The Brantford Insider |
|
|
|
|
|
|
#113 | ||
|
👏 REVOLUTIONARY 👏
Industry Role:
Join Date: Oct 2012
Posts: 2,412
|
Quote:
Then I just use Copilot inside VSCode to start a new agent and I paste that ticket into the chat, where it automatically identifies the AGENTS.md file as a context file, then my ticket as the user prompt, that sets up the hierarchy to make it all work. Then after it finishes I review the changes and request stuff in the chat and it will continue making changes until I decide it's good enough, then I close that chat and repeat the process with the next ticket. Quote:
I'll share my tool here on GFY when I've got it ready for public usage.
__________________
|
||
|
|
|
|
|
#114 |
|
Confirmed User
Industry Role:
Join Date: Jun 2004
Location: Canada
Posts: 3,125
|
How do you make sure the review of the restaurant (or whatever product you build a site for) passes the AI detectors that Google and other SEs are looking out for? I mean the paragraphs of text (article) that make up the review?
|
|
|
|
|
|
#115 |
|
The FraudBuster
Industry Role:
Join Date: Aug 2024
Location: Brantford, Ontario
Posts: 579
|
I don't even worry about it. Everything in that text is based on factual information that I get from the API. It's no problem.
__________________
The Brantford Insider |
|
|
|
|
|
#116 |
|
Confirmed User
Industry Role:
Join Date: Jun 2004
Location: Canada
Posts: 3,125
|
Thanks. I guess I'm not sure what the AI detectors are actually looking for. Even though the information is factual, is it possible that Google detects the writing style as AI writing and penalizes you?
|
|
|
|
|
|
#117 | |
|
The FraudBuster
Industry Role:
Join Date: Aug 2024
Location: Brantford, Ontario
Posts: 579
|
Quote:
It's from Google it gets labeled as from Google, and the link goes to the Google Places page. Same thing if its from Trip Advisor. If I can't pull enough restaurants or any type of business from one source, I can simply pull from another or even all of them, my system tracks it all and gives proper attribution as the platform's TOS states they should. Google can see it's not a bunch of made up bullshit, in other words. It's not copy and paste, it's all original content. It all happens at a speed of 2 restaurant listings per minute once it's going. I'm still laughing at the "this is scaping and stealing" comment someone else posted above. ![]()
__________________
The Brantford Insider |
|
|
|
|
|
|
#118 | |
|
making it rain
Industry Role:
Join Date: Oct 2003
Location: seattle
Posts: 22,176
|
Quote:
The endgame of Google is to serve up its own AI summary and keep you there anyway. |
|
|
|
|
|
|
#119 |
|
Confirmed User
Industry Role:
Join Date: Jun 2004
Location: Canada
Posts: 3,125
|
When you say 'slop', do you mean after reading one sentence a 6th grader can tell it's AI? Or more covert seeming AI writing?
I thought they wanted you to click on their ads. But it does seem that G always has their AI give answers first. |
|
|
|
|
|
#120 | |
|
The FraudBuster
Industry Role:
Join Date: Aug 2024
Location: Brantford, Ontario
Posts: 579
|
Quote:
![]()
__________________
The Brantford Insider |
|
|
|
|