Forem: Livrädo Sandoval

Should anonymous contributions be allowed in open source?

Livrädo Sandoval — Tue, 07 Apr 2026 20:00:00 +0000

Open source has always been built on a simple idea:

Transparency builds trust.

You can see who wrote the code, who reviewed it, and how decisions were made. Identity is part of the system.

But that assumption is starting to be questioned.

With growing concerns around privacy, harassment, and professional risk, a new question is emerging:

Should anonymous contributions be allowed in open source?

Not as an edge case — but as a first-class option.

The case for anonymity

Let’s start with why this idea is gaining traction.

1. Privacy is no longer optional

A Git commit is not just code. It’s identity.

Name
Email
Activity history
Contribution patterns

Over time, this creates a detailed public profile.

For some developers, that’s fine. For others, it’s exposure they never really agreed to.

Anonymity gives contributors control over what they reveal — and what they don’t.

2. Safety and risk mitigation

Not all contributions are neutral.

Some developers contribute to:

Politically sensitive projects
Privacy tools
Software their employer may not support

In some regions or contexts, visibility can carry real consequences.

Anonymity isn’t about hiding.
It’s about reducing unnecessary risk.

3. Lowering the barrier to entry

Open source can be intimidating.

Especially for:

New developers
People dealing with impostor syndrome
Contributors from underrepresented groups

When identity is attached, contribution becomes personal.

When identity is removed, contribution becomes technical.

That shift can make it easier to:

Open your first PR
Ask questions
Participate without fear of judgment

4. Reducing noise around reputation

Not every contribution needs to be a signal.

Sometimes you just want to:

Fix a typo
Suggest a small improvement
Help without building a “public track record”

Anonymity allows contribution without turning everything into reputation capital.

The case against anonymity

Now the other side — and it’s just as important.

1. Accountability matters

Open source relies on trust.

Maintainers need to know:

Who is contributing
Whether they have a track record
If they can be trusted over time

Anonymous contributions remove that layer.

If something goes wrong:

Who is responsible?
Who do you follow up with?
Who builds long-term trust?

2. Increased risk of abuse

Without identity, barriers drop — for everyone.

Including bad actors.

Potential risks:

Spam PRs
Malicious code submissions
Harassment through issues/comments

Most platforms already struggle with moderation.

Anonymity can amplify that challenge.

3. Harder collaboration

Open source is not just about code.

It’s about relationships.

Long-term contributors
Maintainer trust
Ongoing discussions

Identity helps build continuity.

Without it, every interaction can feel like starting from zero.

4. Reputation is part of the incentive

Let’s be honest:

Many developers contribute to open source because it:

Builds credibility
Helps with jobs
Strengthens their public profile

If anonymity becomes the norm, that incentive weakens.

And that could reduce participation in some contexts.

So… what’s the right balance?

This isn’t a binary choice.

It’s not:

Full anonymity vs
Full transparency

The more interesting question is:

Where should anonymity be allowed — and where shouldn’t it?

Some possibilities:

Anonymous contributions allowed, but clearly labeled
Maintainers choose whether to accept them
Rate limits and validation to reduce abuse
No anonymity for critical infrastructure projects
Optional anonymity for low-risk contributions

In other words:

Make anonymity a tool — not the default.

A practical example

Tools like gitGost are exploring this space.

They allow developers to:

Open pull requests
Comment on issues
Contribute code

…without attaching personal identity.

But they don’t remove accountability entirely:

All contributions are still public
Maintainers review everything
Abuse can still be moderated

The difference is:

Identity is no longer required to participate.

My take

Open source should be about contribution quality, not identity exposure.

But removing identity completely, everywhere, would be a mistake.

A better approach:

Keep transparency where it matters (core maintainers, critical systems)
Allow anonymity where risk is low and contribution is small
Give maintainers control over their boundaries

Anonymity should not replace identity.

But it should exist as a legitimate option.

The real question

This debate is not just technical.

It’s cultural.

Open source has always assumed that:

“If you have nothing to hide, you have nothing to fear.”

That assumption doesn’t hold as well anymore.

So the real question becomes:

Should contributing to open source require exposing your identity?

Or should that be a choice?

I’m curious where you stand.

Would you accept anonymous PRs in your repo?
Have you ever avoided contributing because of visibility?
Do you see anonymity as a feature — or a risk?

Let’s discuss.

How anonymous is GitHub… really?

Livrädo Sandoval — Mon, 06 Apr 2026 18:00:00 +0000

GitHub feels public.

But not that public.

You push a commit, open a PR, maybe use a username that isn’t your real name… and it feels “safe enough”.

But here’s the real question:

How anonymous are you actually?

Let’s break it down.

What a normal commit really exposes

Every Git commit contains more than just code.

A typical commit includes:

Author name
Author email
Commit timestamp
Commit message
Diff (your actual changes)

Even if you’re using a pseudonym, your email is often the real identifier.

And yes — it’s public.

Email leakage is more common than you think

Unless you’ve explicitly configured GitHub’s email privacy settings, your commits may expose your real email.

Even worse:

Old commits may still contain it
Forks and mirrors preserve that data
Anyone can scrape it at scale

This has led to:

Spam campaigns
Targeted phishing
Identity correlation across platforms

Once your email is in the Git history… it’s effectively permanent.

Metadata goes deeper than identity

Even if you hide your name and email, Git still leaks signals.

Things like:

Time patterns (when you commit)
Writing style in commit messages
Code style and structure
File naming conventions

This is where stylometry comes in — analyzing patterns to identify authors.

You don’t need your real name attached to be recognizable.

🍴 Forks make everything traceable

GitHub’s model is built around forks.

When you:

Fork a repository
Create a branch
Open a Pull Request

You’re creating a public, traceable graph.

Anyone can see:

Where the fork came from
When it was created
How it evolved
Who contributed

Even if you delete your fork later, traces often remain:

Cached data
PR references
External mirrors

In short:

Git is immutable by design. And GitHub builds visibility on top of that.

So… what’s the actual threat model?

Let’s be realistic.

GitHub doesn’t exist to deanonymize you — but it also doesn’t protect your anonymity.

It does expose you to:

Recruiters / HR scanning your history
Maintainers judging your contributions
Email scrapers and bots
Casual observers correlating activity

It does not protect against:

Identity linking via email reuse
Behavioral analysis (timing, style)
Public metadata aggregation

And it definitely doesn’t hide:

Your IP (when interacting via the web)
Your activity patterns over time

GitHub is built for transparency and attribution.

Not privacy.

“But I use a different username…”

That helps.

But it’s not enough.

If any of these are true:

You reused an email somewhere else
You linked your account to social profiles
You commit in consistent time windows
You write in a recognizable way

Then your “anonymous” identity becomes… linkable.

Not instantly.

But gradually.

👻 A different model: anonymous contributions

What if you could contribute without attaching identity at all?

No name.
No email.
No account.

That’s where gitGost comes in.

How gitGost changes the flow

Instead of pushing directly to GitHub, you push through gitGost:

git remote add gost https://gitgost.leapcell.app/v1/gh/owner/repo
git push gost my-branch:main

What happens next:

Your commit is stripped of identifying metadata
A Pull Request is created via a neutral bot
Your message becomes the PR description

Result:

The contribution is visible
The code is reviewable
You are not

What about IP tracking?

Important detail:

gitGost removes Git-level identity, but your IP can still be visible to the server.

If you want stronger anonymity, you can route your connection through Tor.

🧅 Using Tor for network-level privacy

Example (Linux/macOS):

torsocks git push gost my-branch:main

This routes your traffic through the Tor network.

So instead of your real IP, the server sees:

A Tor exit node
Not your actual location

Now you have:

No name
No email
No direct IP

That’s a much stronger anonymity model.

⚠️ Let’s be honest: perfect anonymity doesn’t exist

Even with tools like gitGost + Tor, some risks remain:

Advanced stylometry
Correlating timing across platforms
Reusing unique phrases
Mixing anonymous and identified contributions

Anonymity is not a switch.

It’s a spectrum.

When does this actually matter?

Not every contribution needs anonymity.

But in some cases, it really does:

Contributing to controversial projects
Avoiding employer conflicts
Reducing spam and scraping exposure
Making small contributions without permanent identity linkage

Or simply:

You don’t want every typo fix tied to your name forever.

Final thought

GitHub is excellent at what it was designed for:

Collaboration through transparency.

But transparency comes with trade-offs.

If you’ve ever assumed you were “kind of anonymous”…

Now you know the truth.

You’re not.

Unless you choose to be.

The hidden cost of contributing to open source

Livrädo Sandoval — Sun, 05 Apr 2026 14:05:53 +0000

Open source is supposed to be liberating.

You learn in public, collaborate with strangers, and build a reputation that compounds over time. At least, that’s the narrative.

But there’s a quieter side that almost nobody talks about.

A cost that doesn’t show up in GitHub stats.

A cost that lives in your head.

The pressure of “build in public”

“Build in public” started as a healthy movement.

Share your progress. Be transparent. Help others learn.

But somewhere along the way, it turned into performance.

Every commit becomes a statement.
Every PR becomes a reflection of your skill.
Every comment feels like it's being judged.

You’re no longer just fixing a bug — you’re being watched while doing it.

And even if nobody is actually watching… it feels like they are.

That subtle shift changes everything.

Fear of being wrong — in public

Making mistakes is part of engineering.

But making mistakes in front of everyone is something else.

What if the maintainer thinks this is dumb?
What if someone points out something obvious I missed?
What if this PR exposes that I’m not as good as I think?

So instead of contributing, you hesitate.

You rewrite the same commit five times.
You over-explain.
Or worse — you don’t open the PR at all.

Not because you can’t.

Because you don’t want to be wrong in public.

The quiet impostor syndrome in PRs

Impostor syndrome hits differently in open source.

At work, your mistakes are contained.
In open source, they’re permanent. Indexed. Searchable.

Attached to your name.

That creates a strange internal dialogue:

“Do I really belong contributing here?”

Even experienced developers feel it when contributing to unfamiliar repos.

You’re stepping into someone else’s codebase, their standards, their expectations.

And your name is right there, attached to whatever you submit.

Exposure anxiety is real

There’s also a more practical layer: exposure.

Public commits reveal:

Your name
Your email
Your activity patterns
Your interests

Over time, this builds a detailed profile.

For some, that’s fine.

For others, it’s uncomfortable — or even risky.

Maybe your employer wouldn’t approve of certain contributions
Maybe you don’t want your activity permanently tied to your identity
Maybe you’ve experienced spam, scraping, or worse

Open source assumes visibility is harmless.

That’s not always true.

So what happens?

A lot of developers silently opt out.

Not because they don’t care.
Not because they’re not capable.

But because the psychological cost is too high.

They:

Avoid contributing to larger projects
Stick to private repos
Or only engage where they feel “safe enough”

Open source loses contributions it never even knew existed.

A different approach: contribution without exposure

What if contributing didn’t require attaching your identity?

What if you could:

Fix a bug
Improve documentation
Participate in discussions

…without turning it into a permanent public record tied to your name?

That’s the idea behind gitGost.

👻 Contribute like a ghost

With gitGost, you can contribute to any GitHub repository:

No account
No tokens
No personal metadata

Just:

git remote add gost https://gitgost.leapcell.app/v1/gh/owner/repo
git push gost my-branch:main

Your contribution still goes through the same process:

A Pull Request is created
Maintainers review it
Feedback happens as usual

But your identity isn’t part of the equation.

Why this matters

This isn’t about removing accountability.

Maintainers still review every PR.
Code still needs to be correct.
Discussion still happens.

What changes is who you have to be while contributing.

You’re no longer:

Protecting your reputation
Managing your public image
Second-guessing every small mistake

You’re just solving the problem.

Not everything needs your name attached

Some contributions are meaningful milestones.

Others are:

Fixing a typo
Refactoring a small function
Suggesting a minor improvement

Do those really need to live forever under your identity?

Maybe.

But maybe not.

Final thought

Open source should lower barriers — not introduce new invisible ones.

Skill shouldn’t be blocked by fear.
Contribution shouldn’t require exposure.

And sometimes…

The best way to contribute
is to disappear.

Launching CodeTrackr 0.2.0 🚀

Livrädo Sandoval — Sun, 05 Apr 2026 13:56:26 +0000

I am excited to announce the next evolution of CodeTrackr — a privacy-first, real-time developer analytics platform built for those who want full control over their data.

CodeTrackr automatically tracks your coding activity, generates live insights, and gives you powerful tools to understand and improve your workflow — without sacrificing your privacy.

We’ve shipped a ton of new features designed to help you code smarter, build faster, and stay in control.

So, how can you use CodeTrackr to level up as a developer?

This is an experimental project still in the BETA phase.

Web: https://codetrackr.leapcell.app
Repo: https://github.com/livrasand/CodeTrackr

🚀 Level up faster

Here’s what you can do with CodeTrackr:

💪 Track everything automatically
No setup friction. Just install the extension, add your API key, and start sending heartbeats instantly. Every coding session is tracked in real time — across any editor.

💻 See your coding activity live
Watch your stats update as you type. CodeTrackr provides real-time analytics, including total coding time, languages used, and project breakdowns — all from a clean dashboard.

📊 Own your data
Export your full history anytime in JSON or CSV. No paywalls. No lock-in. Your data belongs to you — always.

📈 Compete and explore with leaderboards
See how you rank globally by language, editor, or total time. Discover other developers and track your progress over time with live leaderboards powered by real-time infrastructure.

🔌 Build your own plugins
Extend CodeTrackr your way. Create dashboard plugins using simple JavaScript — no backend required. Publish once, and every user can install it instantly.

🧠 Works with any editor
VS Code, Neovim, IntelliJ, Emacs, Zed — anything that can send an HTTP request can integrate with CodeTrackr. One endpoint. Full tracking.

Drop-in API
Already using another tracking tool? CodeTrackr offers a compatible heartbeat API:

POST /api/v1/heartbeat
X-API-Key: ct_your_key
{ "project": "my-app", "lang": "rust" }

Switching takes minutes.

🔐 Privacy-first by design

No tracking scripts
No data selling
Anonymous accounts supported
Self-hostable with full control

You can even run everything locally using Docker.

🧰 Build with CodeTrackr

CodeTrackr isn’t just a tool — it’s a platform.

Create custom charts, streak systems, or team dashboards
Publish IDE extensions for any environment
Ship plugins that run directly in the browser

All without managing infrastructure.

⚙️ Getting started

Getting started is simple:

Sign in (or create an anonymous account)
Generate your API key
Install the extension in your editor
Paste your key — done

That’s it. You’re now tracking your coding activity in real time.

💸 Pricing

Free — full-featured for individual developers
Pro Cloud ($2/mo) — unlimited history + extra features
Self-hosted — run everything yourself with zero telemetry

🌍 The vision

CodeTrackr is built on a simple idea:
developer metrics should be transparent, local-first, and owned by you.

No black boxes. No hidden tracking. No compromises.

🔥 Try it now

Install the extension, start tracking, and take control of your coding data.

Have ideas for the next version?
We’re building this in the open — your feedback shapes what comes next.

Your GitHub history is being used against you

Livrädo Sandoval — Tue, 31 Mar 2026 13:50:02 +0000

For years we were told that building publicly was the best way to grow as a developer. “Share your code”, “document your process”, “make constant commits”. And yes… all of that works. Until he stops doing it.

Hoy, tu historial en GitHub no solo muestra lo que sabes hacer. It also shows who you were, what you thought and what you believed in… and that can work against you.

Web: https://gitgost.leapcell.app
Repo: https://github.com/livrasand/gitGost

The uncomfortable side of commits

Every commit you make tells a story. Not only technical, but personal.

Recruiters and companies no longer limit themselves to seeing your CV. They review:

What projects have you touched
How you write your commit messages
What technical decisions did you make
How you interact in issues and pull requests

This may seem fair… until it isn't.

Because that context is almost never complete. A commit does not explain:

*if you were learning
*if it was an experiment
*if it was a temporary bad decision
*or if you simply changed your mind later

However, it remains there. Permanent.

Your opinions are also recorded

GitHub is not just code. It's discussion.

Every comment on an issue, every technical debate, every position on architecture... everything is associated with your identity.

And here the problem begins.

Technical opinions evolve. What you defended 2 years ago may seem like a mistake to you today. But on GitHub there is no “emotional context” or “personal evolution.” There are only records.

Even worse:

You may be perceived as conflictive due to a specific debate
As inexperienced by old decisions
Or as rigid for defending something you no longer think about

Your history does not distinguish between growth and contradiction. It only shows traces.

Contribute to the “wrong”

Open source has an idealistic narrative… but the reality is more complex.

What happens if you contribute to:

a project with a controversial philosophy?
a tool that later becomes controversial?
a repository associated with questionable decisions?

Even if your contribution has been technical, neutral or even minimal... your name remains there.

And someone, at some point, can interpret that without context.

It doesn't matter if it was years ago. It doesn't matter if you no longer agree.

It's in your history.

The permanent digital identity

This is where everything converges.

Your GitHub profile becomes a kind of “permanent digital identity”:

*Does not expire

Does not restart *Does not forget

Unlike real life, where you can change, learn and redefine yourself... on the internet everything is indexed, accessible and evaluable.

And that creates a real tension:

*Build in public or protect your privacy?

Be transparent or be cautious?
Experiment freely or take care of your reputation?

So... do we stop contributing?

Not necessarily.

But it is worth questioning the idea that everything must be done publicly and permanently.

There is space for:

experiment without pressure *contribute without full exposure
explore ideas without them defining your long-term identity

In this context, different approaches are beginning to emerge. Tools that allow the contribution to be separated from the personal trace, or at least give the developer more control over what is associated with their identity.

It's not about hiding bad intentions.
It is about recovering something basic: the right to evolve without your technical past haunting you forever.

An uncomfortable reflection

Quizá la pregunta no es si debes construir en público.

Otherwise:
how much of yourself are you willing to leave permanently recorded?

Because in the end, not everything you create today represents who you will be tomorrow.

How to protect your submissions on gitGost using Tor for complete anonymity

Livrädo Sandoval — Sun, 29 Mar 2026 14:51:15 +0000

Hello again!

Thank you again for taking the time to read this. When contributing to open source projects, maintaining your privacy can be essential, especially if your contributions cover sensitive topics or you prefer not to expose your identity or location. gitGost already removes your name, email and metadata in your commits, but there is still one important piece of information: your IP address. How to prevent this last clue from giving you away? The answer is simple and effective: use Tor.

Why use Tor together with gitGost?

gitGost hides who you are at the Git level, but it can't hide where you are on the network. When you connect over the Tor network, your traffic is routed through multiple nodes before reaching the server, which prevents even the gitGost server from identifying your real IP.

This means that your anonymity is reinforced with a double layer: gitGost protects your identity in the repository; Tor protects your footprint on the Internet.

gitGost hides who you are in Git, Tor hides where you are on the network.

Importance of hiding your IP

Even if a system keeps no logs or little data, your IP address is exposed momentarily at the network layer when sending the request. This information may be enough to link you to a contribution, especially if it is a sensitive action.

With Tor, your connection is camouflaged behind a globally distributed chain of nodes, making tracing the true origin virtually impossible.

How to configure Tor to send anonymous commits

On Linux and macOS

Install the Tor package and torsocks to redirect git traffic over the Tor network:

# Install tor + torsocks
$ sudo apt install tor torsocks # Debian/Ubuntu
$ sudo pacman -S tor torsocks # Arch
$ brew install tor torsocks # macOS

Start the Tor daemon:

$ sudo systemctl start tor # Linux
$ brew services start tor # macOS

Verify that your IP is correctly masked:

$torsocks curl https://check.torproject.org/api/ip
→ {"IsTor": true, "IP": "185.220.101.x"}

Finally, push your changes through Tor using git with gitGost:

$torsocks git\
    -c http.extraHeader="X-Gost-Authorship-Confirmed: 1" \
    push gost my-branch:main
→ PR opened as @gitgost-anonymous — server sees Tor exit node, not you

On Windows without WSL

It uses the Tor browser, which runs a local SOCKS5 proxy at 127.0.0.1:9150. Then configure Git to use that proxy:

$git config http.proxy socks5h://127.0.0.1:9150
$git config http.extraHeader "X-Gost-Authorship-Confirmed: 1"

Do the push normally:

$ git push gost my-branch:main
→ PR opened as @gitgost-anonymous — server sees Tor exit node, not you

On Windows with WSL2

Here you can follow the same steps as in Linux:

$ sudo apt install tor torsocks
$ sudo service tor start

$torsocks git\
    -c http.extraHeader="X-Gost-Authorship-Confirmed: 1" \
    push gost my-branch:main
→ PR opened as @gitgost-anonymous

Considerations and limitations

While Tor extends your anonymity, it also comes with some compromises you should keep in mind:

Slower connection: Routing through multiple nodes introduces latency.
Trust in exit nodes: although the content travels encrypted (HTTPS) to the server, the node where your traffic leaves is public.
Operational consistency: Privacy depends on using these tools in a disciplined way, without mixing identities or direct connections.

gitGost does not replace Tor, but complements it perfectly: one protects your identity within the code, the other protects your footprint on the network.

Final reflection on privacy in open source

True privacy is built by adding layers and measurements. Only gitGost reduces personal traces in your commits, but combining it with Tor takes that protection to the next level, hiding both visible identity and location.

For some this level of anonymity may be unnecessary, but for others it means the difference between not participating and being able to do so safely and freely.

In essence, it is about making the world of open source truly accessible to those who prefer to contribute without leaving traces that expose them. Because open source is also for those who choose to remain invisible.

Contribute to open source projects without leaving a trace: a new way to collaborate on GitHub

Livrädo Sandoval — Fri, 27 Mar 2026 17:30:53 +0000

Hello everyone!

Due to conflicts of interest, I had to delete the previous posts, but these days, I will start publishing again some posts related to privacy and security, and how some of my tools can help in that aspect. Also, I would love to receive feedback from you on this software you made, and areas for improvement.

Also, I want to say that for the translation of my posts I use ChatGPT, I do not use it to create my posts, but to translate, the posts are written entirely by me.

Thank you very much in advance for taking the time to visit this post, if you want to see the gitGost website visit this link: https://gitgost.leapcell.app
If you want to see the code, visit this link: https://github.com/livrasand/gitGost

In the world of development, collaboration is key. But what happens when contributing to a project means revealing our identity, exposing us to immutable public history or possible privacy risks? This is where gitGost comes in, a tool that rethinks how we interact with repositories on GitHub, offering a layer of anonymity and privacy that we haven't seen before.

What is gitGost?

gitGost allows any developer to contribute to GitHub repositories without leaving personal footprints. With a privacy-first approach, it requires no accounts or tokens – just a simple command is enough to connect your local repository to gitGost and start pushing your changes. Behind the simplicity, there is a robust system built in Go, which guarantees security, anonymity and ease of use.

Privacy in the foreground

Contributions made through gitGost remove all personal metadata — names, emails, dates, and even IPs if combined with Tor. Pull Requests are automatically created from a generic anonymous identity (@gitgost-anonymous), and all communications are stored minimally, with no personal data, just a counter, the repository name and the URL of the PR.

In addition, gitGost offers the possibility of receiving anonymous notifications about the status of your PRs through the ntfy.sh service, without needing to register or provide an email. This way, you can stay up to date with comments, reviews, and merges without exposing your identity or compromising your privacy.

Simple and flexible collaboration

The workflow boils down to three clear steps: add gitGost as a remote, commit your changes, and push to the remote anonymously. For those who receive feedback, they can update the same anonymous PR using a unique hash provided by gitGost, without storing data or requiring accounts. This makes the contribution as seamless and practical as in the traditional flow, but without the cost of exposition.

Security and transparency

gitGost is built on secure, auditable practices, with built-in validations, contribution size limits, and no unnecessary dependencies. It is licensed under AGPL-3.0 and its code is available for anyone who wants to review it, promoting trust and transparency around how it handles information.

Who is gitGost for?

Developers who value their privacy: Those who prefer not to leave a permanent public history tied to their name.
Collaborators in sensitive contexts: People who need to contribute to possibly controversial or restricted projects without exposing themselves.
Those who want to avoid spam or doxxing: gitGost removes common traces that bots use to collect data.
Those who make minor or quick changes: Sometimes a small correction shouldn't be etched with your identity forever.

Live the gitGost experience

From a simple text correction in a README to opening an anonymous discussion in an issue, gitGost opens a new chapter in open source collaboration: one where your security and anonymity come first, without giving up the convenience and effectiveness of git.

If there is one thing that characterizes the open source community, it is the diversity of voices working together. gitGost expands that diversity by allowing more people to participate, even if they prefer to be just a whisper in the conversation.

Exploring this tool is as easy as adding a remote and pushing. In a world where we increasingly look with concern at how to protect our digital privacy, gitGost represents a ray of hope to contribute freely, without chains.

I will try to publish a post every day to present gitGost, EthicalMetrics, Hushlink, CodeTrackr, pipq and PythonICO, again, your feedback will help me a lot