Commenting on BLURT Without an Account? Introducing Blurt Guest Gateway — A System Other Frontends Can Use Too!

For quite some time, I've been thinking about how to make it easier for people outside the BLURT community to use our websites and take part in discussions.

Blockchain offers many interesting possibilities, but it also comes with a certain barrier to entry. To leave a simple comment under an article, you first need to create an account, understand how the different keys work, and learn how to log in.

For people who already use BLURT, this isn't much of a problem. But what about someone who happens to find an interesting article through Google? Not necessarily so simple.

That's why I decided to create a solution that allows people to comment on posts on the BLURT blockchain without having their own account.

And that's how Blurt Guest Gateway was born.

For now, I've implemented it on blurt.pl, where guest commenting is already available. However, from the very beginning, I designed it not as a feature limited to a single website, but as a standalone application with an API that can be integrated with other frontends supporting the BLURT blockchain.

And that's exactly what I'd now like to make available to other developers.

What Does Commenting Without an Account Look Like?

I tried to make the entire process as simple as possible.

Someone reading an article on blurt.pl can either log in traditionally using their BLURT account or choose the new option: "Use Guest Account".

With the second option, there's no need to install browser extensions, possess cryptographic keys, or even understand how blockchain works.

All the visitor needs to do is:

1. Enter a nickname of their choice.
2. Write a comment.
3. Confirm that they understand the public nature of blockchain publishing.
4. Submit the message.

The comment is then sent to an AI-assisted verification system and, once approved, published directly to the BLURT blockchain.

Importantly, this isn't a separate commenting system where messages are stored only in my website's database.

These are real blockchain comments.

Once published, they become part of the discussion under the original post and can also be accessed through other BLURT frontends.

How Does It Work Without Registration? Every Frontend Can Have Its Own Guest Account

The solution is based on dedicated guest accounts.

For blurt.pl, I created the @blurtpl-guest account, which publishes comments on behalf of visitors who aren't logged into my website.

But importantly, this doesn't mean every frontend has to use the same account.

Every frontend can have its own completely independent BLURT guest account.

For example:

• blurt.pl — uses my @blurtpl-guest account.
• blurt.blog — could create its own account, such as @blurtblog-guest, owned and controlled independently by the operator of blurt.blog.
• Another BLURT frontend — could create a different technical account dedicated exclusively to its own application.

Of course, these are just example names and don't mean that all these accounts already exist.

Each frontend owner would retain control over their own guest account, while Guest Gateway would provide the shared infrastructure for receiving, moderating, and publishing comments.

There's no need to publish every guest comment through one shared account or to use my @blurtpl-guest account.

The visitor's chosen nickname is included in the comment itself. However, it's important to remember that this nickname is not a full blockchain account — the actual on-chain author remains the guest account associated with the frontend.

This is a deliberate compromise that significantly lowers the barrier to entry.

Automatic Comment Verification Using AI

One of the biggest challenges was, of course, spam.

A public comment form that doesn't require logging in can quickly become a target for advertising bots, scammers, or people spreading suspicious links.

However, I didn't want to build a system where I would have to manually approve every single comment.

That's why I integrated Blurt Guest Gateway with Gemini AI, which I already use in another system to assist with verifying new BLURT account registrations.

Every new guest comment can be automatically analyzed by AI before being sent for publication on the blockchain.

Among other things, the system checks whether a message:

• Contains spam or automatically generated advertising.
• Includes suspicious links, phishing attempts, or scams.
• Appears to be mass-distributed content.
• Requires additional review by a human moderator.

Based on its analysis, the AI can approve a comment, send it for manual moderation, or reject it as a clear case of abuse.

At the same time, I wanted to make sure that artificial intelligence wouldn't become a tool for suppressing inconvenient opinions.

Criticism, controversial views, or simply disagreeing with the author of an article should not be reasons to reject a comment.

The primary purpose of AI is to reduce spam and abuse, not to decide which opinions people are allowed to express.

Additionally, if Gemini doesn't respond or cannot confidently evaluate a comment, the message can be sent for manual review instead of being published automatically.

This is also important for other frontends. A website owner integrating with Guest Gateway doesn't need to build an entire AI moderation infrastructure from scratch.

Guest Gateway Is More Than Just a Solution for blurt.pl

This is the part I find most interesting.

I could have created a simple guest commenting system that works only on my website, but I decided to take it a step further.

I built the entire mechanism as an independent application that provides an API.

As a result, other BLURT frontends don't have to build their own infrastructure for AI moderation, key management, transaction signing, publication status tracking, or communication with RPC nodes.

They can simply connect to my system.

I've also created an administration panel where applications can be managed, individual guest accounts can be assigned to them, and separate API keys can be generated.

Each frontend can use its own configuration, its own limits, and its own BLURT account.

For example, blurt.pl and blurt.blog could use the same Guest Gateway infrastructure, while comments from blurt.pl visitors would be published through @blurtpl-guest, and comments from blurt.blog visitors would be published through an account belonging to the operator of blurt.blog.

Both applications would operate independently when it comes to accounts, API secrets, and assigned permissions.

What Does It Take to Connect Your Own Frontend?

The integration itself isn't particularly complicated.

In practice, all you need to do is:

1. Have a BLURT account dedicated to guest commenting. I recommend creating a separate technical account, just as I did with @blurtpl-guest.
2. Configure the account in Guest Gateway by providing its Posting Key, which will be used to sign and publish guest comments.
3. Generate your own API key in the application management panel.
4. Connect the API to your frontend and create a comment form for visitors who aren't logged in.

And that's pretty much it.

Guest Gateway takes care of everything else, including receiving comments, verifying them with Gemini AI, queuing them, signing transactions, and publishing them to the blockchain.

There's no need to deploy a separate infrastructure for every frontend.

What About the Security of the Posting Key?

Of course, sharing cryptographic keys always requires caution.

However, in this case, we're talking about the Posting Key of a dedicated guest account, not the Owner or Active Key used for higher-privilege account operations and managing funds.

In my opinion, when using a separate technical account that isn't intended to hold significant funds, the risks are much easier to limit.

A Posting Key doesn't provide the same permissions as an Active or Owner Key, but it still allows someone to perform publishing operations on behalf of the account. If compromised, it could therefore be used for unwanted publications, spam, or operations that generate fees.

That's why I strongly recommend creating a dedicated guest account and providing its key only through the secured administration panel.

There's no need to share an Active or Owner Key. A Posting Key is sufficient.

A Separate Management Panel for Frontend Owners

I've also created a permission management system, so I don't need to give other users access to the entire infrastructure.

I can grant a specific BLURT user access only to their own applications and assigned guest account.

After logging in with their own BLURT account, users can manage the resources assigned to them.

Depending on their permissions, they can configure their application, manage its API key and limits, and moderate comments.

They cannot access applications belonging to other users or view their private keys.

This means that a single Guest Gateway instance can support multiple independent frontends and guest accounts.

The Project Is Still in Testing — Other Developers Are Welcome!

Although the system is already running on blurt.pl and I've successfully published the first real guest comments to the blockchain, I still consider the whole project to be in its testing phase.

I'd like to see how it performs with a larger number of comments, different frontends, and multiple independent guest accounts.

That's why I'm happy to provide access to BLURT developers who are interested in trying it out.

For now, I grant access to the management panel manually. Once access has been provided, developers can generate their own Guest API key, configure their application, and assign an appropriate guest account.

A Few Technical Details for Developers

The application runs on blurtplugin.online, independently of the blurt.pl frontend.

Communication takes place over HTTPS using an API and an individual secret assigned to each application.

The current endpoint is:

`https://blurtplugin.online/bg-entry.php`

How Does the Comment Publishing Process Work?

1. The frontend receives a comment.

The visitor enters a nickname and comment text. The frontend also knows the author and identifier of the BLURT post under which the comment should appear.

2. The frontend backend contacts the Guest API.

The request contains the comment data and the application's API secret. The secret itself should remain on the server side — it should never be included in publicly accessible JavaScript.

3. Guest Gateway validates the submission.

The system verifies the application, its limits, and the submitted data, then stores the request in its database.

4. Gemini AI analyzes the comment.

This is one of the more important parts of the solution. Before a comment is published, AI can automatically examine its content for spam, phishing, and other types of abuse.

Approved comments are placed in the publication queue, while uncertain cases may require manual moderation.

5. A worker publishes approved comments.

A separate background process retrieves comments from the queue, signs them using the Posting Key of the assigned guest account, and submits them to the BLURT network through RPC.

6. Guest Gateway monitors the publication status.

The system checks whether a comment has actually been published and makes its current status available through the API.

This means the frontend doesn't have to handle transaction signing, RPC node failures, or publication retry mechanisms on its own.

How Can a Frontend Check a Comment's Status?

After submitting a comment, the API returns an identifier that can later be used to check its status.

Example request:

`GET https://blurtplugin.online/bg-entry.php?id=COMMENT_IDENTIFIER`

The request must be authenticated using the application's API secret.

A comment may be awaiting moderation, sitting in the publication queue, or have a published status, meaning its publication has been confirmed on the blockchain.

This allows the frontend to inform visitors about what's happening with their comments, even when publication isn't immediate.

Is This Solution Decentralized?

Guest Gateway itself is an intermediary service, so its infrastructure, key management, and moderation are centralized.

However, there's nothing preventing others from forking the code in the future and running their own instances if the solution proves useful.

I'm not trying to hide the centralized nature of the current setup.

What matters, though, is that the final destination for published comments is still the BLURT blockchain.

Comments don't exist only in the database of a single website. Once published, they're accessible through other frontends and blockchain nodes.

If blurt.pl ever goes offline, previously published comments will still be stored on the network.

Additionally, each application can use its own guest account, meaning all guest comments don't have to be published through a single shared account.

I believe this is a reasonable compromise between decentralization and accessibility for everyday internet users.

What's Next?

At this point, the most important parts of the system are already working.

I can receive comments from visitors who aren't logged in, automatically verify them using Gemini AI, send them for moderation when necessary, and publish them to the BLURT blockchain.

I've also created an API and a management panel capable of handling multiple applications and independent guest accounts.

Now I'd like to see whether the solution can prove useful beyond blurt.pl.

In my opinion, blockchain shouldn't require every new visitor to immediately create an account and learn all the details of cryptographic keys.

Someone might simply want to read an article, leave a comment, and only later become interested in the platform itself.

Not every first interaction with BLURT has to begin with registration.

If you're developing your own BLURT frontend and would like to test Guest Gateway, feel free to contact me.

I'd be happy to give you access to the panel where you can generate your own Guest API key, and help you with the initial setup, including configuring your own independent guest account.

I'm particularly interested in testing the system with other frontends, as this will help me improve future versions of the application.

I'm looking forward to hearing your feedback, ideas, and from anyone interested in testing it!