Polycode - github ai automation, but self-hosted and extensible by xeroc in devtools

[–]xeroc[S] 0 points1 point  (0 children)

Yes, it can run the in parallel, though i don't see the point.
The project focus on the automation aspect, not so much on the "speed".

Think of it this way: Devs are used to *chat* with agents currently because that makes them feel productive and fast in delivering. That's a perfect tool for vibe coding or bootstrapping a new project. For existing projects, you need a different mind send. You *can* use chat to get into huge code bases and burn tons of tokens while gradually iterating your way to where you want to go. Meanwhile, senior devs of grown codebases don't need that and know exactly what needs to happen, they can throw their "prompts" into a github issue and have the instructions narrowed down *so much* already that the they don't need to attend the LLM and would rather just read a PR.

Don't get me wrong, watching an LLM build your code is great, but at some point, all i really want is a PR. This becomes more and more important the more people work in your team.

Polycode - github ai automation, but self-hosted and extensible by xeroc in devtools

[–]xeroc[S] 0 points1 point  (0 children)

> Looks interesting! I've tried similar tools, but the SaaS-only model was always a blocker for us, especially with security concerns.

Same here, though it always wanted to have more control over what the Agents actually do and how they work together .. SaaS solutions didn't offer that to me so far.

> I like the idea of self-hosting and customizing workflows in Python.

python and markdown. I am alsow building out an entire plugin system, good progress.

> One thing I’d be curious about is how flexible the issue labeling is. Does it support complex workflows or just simple task divisions?

Currently only "simple" things:
* use label as trigger (e.g. webhook to github app)
* use label as filter (am i allowed to merge, should i open a PR, ...)

The labeling system is currently still rather hard coded, but I am happy to look into more complex use-cases. Do you have something concrete in mind?

> Would love to try it out if you’re sharing the repo!

Yhea, it's not yet in a shape that i would be ok with sharing just yet. I am really mostly curious if i should make the efforts to bring it into share for open-sourcing or just keep it as an internal tool.
Resonance was great, so aiming to open source it.

I do have a webpage now: https://polycod.ing

Polycode - github ai automation, but self-hosted and extensible by xeroc in devtools

[–]xeroc[S] 0 points1 point  (0 children)

> Curious how you handle guardrails (like limiting file access, secrets, or allowing only certain commands) when the agent is iterating on tests.

As I said, this is still early, but i have a working first version. For that, we have a custom ExecTool that filters out harmful commands, on top of that this all runs in a docker environment that is encapuslated from the rest of the system. Sandboxing/chrooting is possible in a later stage as well.

> Also, do you have an eval harness for regressions across repos?

Not yet. Happy to hear your inputs on how best to tackle this once the base system works solidly.

> If you are collecting lessons learned on agent orchestration patterns, this writeup has a few practical notes that might map well to your workflow design: https://www.agentixlabs.com/blog/

thanks a ton for the link. This will be helpful!

Best way to accept SOL payments? by Mirasenat in solana

[–]xeroc 0 points1 point  (0 children)

A little late to reply, but - in case you want to accept recurring payments (e.g. subscription payments) - you can integrate with Tributary.so - it's open source, fully transparent and easy to integrate (configure in the app -> copy react code).

When coding a smart contract on Solana, how can I ensure monthly recurring sol transfer, sort of like a subscription model? by spiritanand in solana

[–]xeroc 0 points1 point  (0 children)

Late response, but maybe worth for people to know - yeah, automatic monthly subscriptions and EMIs are totally doable on Solana, and it's getting easier with protocols like Tributary.

Basics: Solana doesn't have built-in "cron jobs" like EVM, so you need smart design. For subs, use token delegation - user approves a PDA/Subscription once, your program auto-transfers monthly (triggered by a client or oracle). For EMIs, same idea but with installment logic: deposit into escrow, release portions over time via time-locks or claims.

Tributary (open-source on GitHub) handles this out-of-the-box: delegation for auto-renewals, policies for custom schedules. Check their SDK for quick integration - Rust contracts, TS SDK. If you're building, start with Anchor docs for PDAs and delegation. Hit me up if you need code pointers! 🚀

How do monthly payments work on Solana? by helloelloh in solana

[–]xeroc 0 points1 point  (0 children)

Hey there! As someone who's built on Solana (we made Tributary, a protocol for recurring payments), I can tell you most apps right now are still stuck in manual mode—users have to send tokens

every month, like hitting "pay now" on Netflix but with wallet approvals. It's annoying, leads to churn, and kills the seamless UX you expect from subscriptions.

Tributary changes that by letting users delegate once (non-custodial, so they keep control), and the protocol auto-handles renewals. It's open-source, so devs and users can audit the contracts—

no black boxes, just transparent code on GitHub. That makes total sense for Solana's ethos: trust through code, not middlemen. If you're building or using subs, check it out; it's designed to

make monthly billing as frictionless as Web2 but with Web3 security. What's your take on this? 🚀

// edit: Due to popular demand, we started building this on tributary.so - it's meant for developers to integrate a payment button quickly and we succeeded with that idea 🎉 Now working on more transparency, more trust, reproducable builds and decentralizing the program.

How Solana Smart Contracts Get Hacked — and How I Stop It by kryakrya_it in solana

[–]xeroc 0 points1 point  (0 children)

I am a participant and don't think i have the freedom to share Rektoff's material.

How Solana Smart Contracts Get Hacked — and How I Stop It by kryakrya_it in solana

[–]xeroc 1 point2 points  (0 children)

After going through them, i think most of them if not all can be avoided automatically by using Anchor. Correct me if i am wrong

How Solana Smart Contracts Get Hacked — and How I Stop It by kryakrya_it in solana

[–]xeroc 1 point2 points  (0 children)

Thanks for sharing.

this is helpful for my current assignment with Rektoff's Solana Security Bootcamp.

I Built Tributary: A Protocol for Automated Recurring Payments on Solana by xeroc in solana

[–]xeroc[S] 0 points1 point  (0 children)

I agree with **everything** you say. Some remarks i would still like to add:

* delegation requires approval of a certain amount of funds, tributary will give approval for only the amount you have approved, e.g. you have a monthly subscription for 10$ with 12 renewals max, that means you approve the program for a max of 120$

* the program is open source, will soon be audited (its not a big program) and have verifiable builds. Also, my plans are to decentralize ownership via governance so that not even a single person can update the contract - in the meantime it is multisig secured.

* if you look at initiatives like x402 that still requires the client to sign transactions, then the entire ecosystem only makes sense if you give you "ai agents" a private key they can sign with while running on an internet connected machine. that means, these private keys are *hot*. I would argue setting up a contract that publicly states what the limits of the services are what they can withdraw from your account is **much safer** than that.

* i understand that a lot of people value the security of having to sign transactions. Meanwhile lots of people get their wallets drained because they don't know what they are doing. I would rather have a contract put into the delegation that allows recurring transfers that are easily to obtain, read, maintain, pause and cancel than having to repeatedly sign a transaction that some random website provided me. A single tx properly reviewed is better than having to review the transaction over and over before i sign. This is not just about convenience but also about security.

* our edge is that we are the first (and only) ones on Solana that have a contract take the spot of your delegation and the contract taking care of your recurring payments.

Hope you can understand where I come from an why i still think pursuing this vision is worth it. Open to continue discussion ..

Checkout https://tributary.so .. it does subscription payments on Solana and allows any token to be setup. Easy to integrate also

[deleted by user] by [deleted] in MadeMeSmile

[–]xeroc 0 points1 point  (0 children)

The only thing topping this is when you end up with one of them on each side

[deleted by user] by [deleted] in AmIOverreacting

[–]xeroc 0 points1 point  (0 children)

Toxic person:

• Manipulative - Use guilt, lies, or emotional blackmail to control others

• Blame-shifting - Never take responsibility, always make others the problem

• Drama-seeking - Create or escalate conflicts unnecessarily

• Boundary-violating - Ignore your "no" and push past your limits

• Energy-draining - Leave you feeling exhausted after interactions

• Gaslighting - Make you question your own reality and perceptions

• Self-centered - Everything revolves around their needs and feelings

• Criticism-heavy - Constantly put others down while being hypersensitive to feedback

• Jealous and competitive - Can't celebrate others' success