Forem: Alfiansa

Elegant Ways to Distribute Commercial Laravel Source Code Without Sacrificing Developer Experience

Alfiansa — Tue, 28 Apr 2026 15:16:10 +0000

Many development teams struggle with the challenges of software distribution architecture.

When we build a commercial product and intend to distribute it with a licensing system, the first instinct is usually to lock down and encrypt the entire codebase.

We feel the need to protect intellectual property strictly so it cannot be pirated or redistributed illegally.

However, field experience shows that blindly encrypting the entire project repository is a fatal mistake.

This paranoid approach makes it difficult for clients to perform fundamental configurations.

For example, adjusting routing, adding custom middleware, or simply modifying the UI to match their brand identity.

In addition to destroying flexibility, full encryption also burdens the server and drastically decreases application performance.

The execution of fully encrypted code requires significantly higher computing resources.

Therefore, we need a smarter and more structured enterprise-level approach.

We must find a balance: exclusive business logic remains secure, while the application framework remains open for exploration and modification by the client.

Separating Core Logic into Private Packages

The key to an elegant distribution architecture is modular separation between the main framework and secret business logic.

Never ship a full Laravel project in an encrypted state.

Instead, extract all crucial "secret sauce" features into their own modules.

Features such as billing systems, core algorithms, and license validation mechanisms should be completely separated from the main application.

Encapsulate all such sensitive logic into a custom Composer package.

For instance, we could name it acme/core-module as an internal naming standard.

By isolating code into a separate package, the main Laravel application directory held by the client remains clean, transparent, and easy to develop.

Once the core logic is isolated, only then do we apply code protection processes.

Encryption and compilation using tools like IonCube or AST (Abstract Syntax Tree) manipulation techniques via yakpro-php are only applied to that acme/core-module package.

The rest of the application outside that package remains readable, standard PHP code.

This approach ensures that only the "brain" of the application is tightly protected, while the other "limbs" are free to move and adapt.

To distribute the compiled package, use a closed distribution ecosystem.

We can utilize Private Packagist or build our own Satis server.

From the client's side, the installation experience remains natural and familiar.

They simply run a standard composer require in the server terminal, include a valid authentication token, and the secret package will be automatically downloaded in an obfuscated format.

Building a Robust License Validation Architecture

Encrypted code alone is not enough without a gateway system that validates access rights.

We need a centralized license server tasked with issuing, managing, and validating every license key.

On the client application side, design a specific Service Provider or Middleware that is always ready to perform HTTP communication with the license server to ensure installation validity.

Ideal license key validation should not just match a string of random characters.

The data payload during verification must bind the license key to the identity of the client's server environment.

Include unique parameters such as the domain name, server IP address, or even the MAC address.

Binding the license to physical and network parameters is important to prevent a single pirated license key from being used across dozens of different installations.

In a client-server implementation, avoid a fatal error: forcing the client application to contact the license server on every page request.

Such an architectural design is terrible for performance.

It is mandatory to implement a solid caching mechanism.

Store license verification results and feature scope status in fast memory like Redis or the local file system.

Set the cache expiration time between 12 to 24 hours.

Besides performance, this cache acts as a safety net during network failures.

The license server might experience downtime, or the client server might suddenly lose internet connection.

In a worst-case scenario, the commercial application should not immediately crash or lock up.

Provide a grace period of several days so the client has time to fix the connection before the system fully deactivates paid features.

Securing Payload Communication with Cryptography

Data security principles from blockchain technology can be adapted to maintain message integrity between servers.

Client developers often have high technical skills, and some might try to bypass the system by rerouting network traffic.

They could create a fake server to mimic our verification responses.

If you rely only on a standard JSON response with a success status, spoofing will be easy to perform.

To counter man-in-the-middle manipulation attacks, implement asymmetric cryptography using the RSA algorithm.

The central license server must hold a strictly secret Private Key.

This private key is used exclusively to sign every data response sent to the client.

This signature is mathematical proof that cannot be forged, confirming the message truly originated from our official server.

On the other hand, the client application hidden inside the encrypted package will store the corresponding Public Key.

When the application receives a response from the server, the first thing it does is verify the digital signature using the public key.

If even a single byte of the response data is manipulated by the client or a third party, the signature verification process will immediately fail mathematically.

The application then automatically blocks overall access.

Integrating License Status with Filament Panels

Once all layers of security architecture and communication logic are running smoothly behind the scenes, the final stage is connecting it to the user interface.

In the modern Laravel ecosystem, Filament is a solid choice for building elegant and interactive administration panels.

We can implement feature flagging concepts directly in the Filament panel provider configuration based on the validated license level.

Retrieve the license scope data previously stored securely in the cache.

Based on regular or premium license status, we can register plugins, render navigation menus, or display pages dynamically.

This conditional logic ensures clients only see and access the interface corresponding to their rights.

public function panel(Panel $panel): Panel
{
    $licenseScope = Cache::get('app_license_scope', 'unlicensed');

    return $panel
        ->default()
        ->id('admin')
        ->path('admin')
        ->plugins([
            $licenseScope === 'premium' ? new \App\Filament\Plugins\AdvancedReportingPlugin() : null,
        ])
        ->navigation(function (NavigationBuilder $builder) use ($licenseScope): NavigationBuilder {
            $navigation = [
                NavigationItem::make('Dashboard')->url(fn (): string => Dashboard::getUrl()),
                NavigationGroup::make('Basic Features')->items([...]),
            ];

            if (in_array($licenseScope, ['premium', 'pro'])) {
                $navigation[] = NavigationGroup::make('Premium Features')->items([...]);
            }

            return $builder->groups(array_filter($navigation));
        });
}

Building an Independent Internet: Mesh Network Experiments and the UDP 53 Hack

Alfiansa — Tue, 28 Apr 2026 15:08:37 +0000

Recently, a friend shared an interesting point: the internet is essentially free and can be bypassed by leveraging UDP 53 access.

I began to realize how fragile the commercial internet network topologies we use today truly are.

Almost all of us depend absolutely on a handful of giant internet service providers.

This architectural model takes the form of a rigidly centralized star topology, where all our hardware—from phones to laptops—must connect to a single central point, such as a cellular tower or a provider's main router.

If that central point experiences a technical glitch or a total blackout due to a power failure, every connected device is automatically paralyzed and loses connection.

There is no backup plan and no alternative path for our data packets to travel.
We can only sit idly waiting for ISP technicians to fix the problem, while on the other hand, there may be people in desperate need of information who remain offline.

This kind of structural dependency makes me uncomfortable, especially in an era where data ownership and digital autonomy are the keys to freedom.

Driven by that curiosity, I began digging for more independent and persistent infrastructure alternatives.

My search led me to a network architecture that isn't exactly new in the networking world, yet its potential is often overlooked by the general public: the mesh network.

This isn't just academic theory, but a tangible form of physical infrastructure decentralization that we can build ourselves alongside local communities.

Physical Decentralization Through Network Nodes

The basic concept of mesh architecture is revolutionary because of its fully decentralized nature.
Unlike traditional networks that force all clients to communicate passively through a single traffic-regulating server, a mesh network allows every piece of hardware within it to act actively as a relay point or transmitter.

These devices communicate directly with one another and forward data packets from one point to another, forming a dynamic ecosystem like a giant spiderweb.

Imagine a practical implementation in a housing complex or a densely populated neighborhood.

Instead of each family shelling out significant money every month for individual fiber optic subscriptions, residents could collaborate to build a community intranet.
Technically, each house would only need to install a directional radio antenna on the roof that continuously broadcasts Wi-Fi signals.

The first house transmits data signals to the second house, the router in the second house inspects the packet and forwards it to the third house, and this cycle continues throughout the neighborhood.

The beauty of this relay system lies in its ability to handle physical obstacles automatically.
This network behavior is highly organic and can adapt to environmental changes without requiring manual intervention from an administrator.

If one day the communication path between the first and second house is blocked by a growing tree or a new building, the routing algorithms in the antenna's firmware will instantly detect the obstruction.

The system will discard the old route and instantly find the most optimal detour.
A user's data packets might be rerouted through the fourth house's antenna before finally reaching the second house safely.

Independent Intranet and Budget Optimization

Building wireless infrastructure independently means the community has full sovereignty over the data traffic in their area.
If the primary goal of the network is only to facilitate local communication between residents, then this digital ecosystem is one hundred percent free with no monthly subscription fees.

All hardware is purchased outright by each individual.
Residents can share large files with each other in seconds without going through the external internet.
Because data packets only circulate within the physical boundaries of the community-built infrastructure, transfer speeds between houses can reach the maximum capacity of the hardware used.
Of course, modern needs don't stop at a local network.

There will come a time when the community needs to access the global internet—for example, to search for information, read news, or enjoy streaming entertainment.
The solution for bridging the local network to the outside world can be solved with very reasonable economic calculations.

The residents' association simply needs to collect collective funds periodically to lease a single high-capacity backbone connection from a top-tier provider.
This central internet connection is then linked to a main router acting as a gateway, distributing bandwidth fairly across the entire mesh network.

The cost of a corporate connection, which is usually very expensive, becomes affordable because it is shared among many participants.

Lessons from Communal Ecosystems

If the concept of self-reliant infrastructure sounds like a utopia, we can look at real-world evidence already running stably in Europe.

In Spain, there is a network initiative called Guifi.net that has successfully broken the dominance of telecommunications corporations.

They started with small steps, connecting a few houses, and continued to expand the mesh network organically until it spanned tens of thousands of kilometers across various cities.

This massive network is entirely owned, configured, and maintained through the mutual cooperation of local residents.

This distributed ownership model creates an infrastructure fortress resilient to both political and technical intervention.
Even government authorities or corporations have no power or ability to shut down their connectivity with a single button.

The ecosystem has no central point or main server room that can be sabotaged to paralyze the entire region.

Every antenna and router transmitting a signal is the private asset of the individual living in that home.

Cutting the power or seizing a device at one node will not cause the system to collapse.
The network algorithm will simply treat the dead node as an obstacle and direct data traffic to hundreds of other operating alternative routes.

This is the most authentic physical form of the philosophy of decentralization.

Protocol Manipulation and Invisible Network Gaps

Exploring network autonomy led me deeper into the aspects of low-level data traffic manipulation.

The topic becomes increasingly interesting when discussing technical methods for obtaining free data access or bypassing firewall restrictions in public areas.
One of the most frequently discussed techniques is the utilization of UDP port 53.

In the global standard internet protocol, UDP port 53 is dedicated entirely to handling Domain Name System (DNS) resolution traffic.

The system's job is to receive the website addresses typed by humans and translate them into the strings of IP address numbers understood by machines.

Why is this port special in the eyes of network hackers?

The reason is rooted in the default security
configurations of almost all public network providers.

System administrators typically block access to standard web application ports for anonymous users who haven't logged in or paid their bills.

However, client devices still need access to display the network provider's login portal page.

To ensure the domain name translation process for the portal can run at the start of a connection, firewalls are forced to let all traffic on UDP port 53 flow freely without strict filtering.

This small gap in security compromise is cleverly exploited to build an invisible data tunnel.

Network experts wrap standard internet data packets—which should run on HTTP or HTTPS ports—and smuggle them into the format of DNS query packets.

This process absolutely requires a private server located outside the reach of public network restrictions.

That external server must be configured to constantly listen for and respond to data packets exclusively through UDP port 53.

On the client side trapped within the closed network, the user employs specially designed tunneling software to route all their browsing activity to that same port.

The local network firewall will inspect the manipulative packets, assume the large sequence of data is just a standard server name lookup request, and let it pass through without suspicion.

Performance Realities and Network Engineering Challenges

While the combination of community topologies and protocol smuggling techniques offers an alternative to centralized infrastructure, both come with several technical compromises.

The most obvious hurdle of the daisy-chain relay method is the drastic increase in response time (latency).

Every time a data packet jumps from one antenna to a neighbor's router, a fraction of time is lost to the inspection and routing process.

The further the physical distance to the destination and the more intermediate points that must be crossed, the higher the connection's ping will swell, eventually becoming difficult to tolerate.

Fluctuating, stuttering connections carry a high risk of causing data communication instability.

Furthermore, there is a massive operational burden in managing hardware at scale that is distributed without a clear hierarchy.

Maintaining route balance so that hundreds of network nodes do not overload a single path requires industrial-grade hardware and deep networking insight.

If a massive mesh network is allowed to grow without a solid automated monitoring system, the initiative will turn into an administrative nightmare.

The method of smuggling data packets through DNS protocol gaps also contradicts the original design of the internet.

Forcing domain resolution infrastructure to carry chunks of video streaming data is as inefficient as forcing a four-wheeled vehicle to travel over railroad tracks.

The resulting transfer speeds are generally very slow, connections often drop randomly, and the data packet loss ratio is quite high.

Knowledge of these guerrilla networking tricks makes me realize the magnitude of the commercial technology engineering challenges we enjoy today.

Studying protocol weaknesses down to the level of bits and bytes always succeeds in expanding technical horizons.
In the end, exploring the extreme limits of network logic is a learning process that shapes us into more conscious users, ready to face even the worst-case scenarios.

Breaking Down How the Lightning Network Works — It's Not Just Magic

Alfiansa — Mon, 27 Apr 2026 05:08:40 +0000

Honestly, I was really curious and finally decided to dig deep into how the Lightning Network (LN) works. Out there, the narrative always says "LN makes Bitcoin cheap and instant," but very few dare to explain the technical details clearly without using analogies that just make your head spin.

As a developer, I need to know the code-level details. If Bitcoin supposedly doesn't have smart contracts as flexible as Ethereum's, then how can LN work without someone running off with the money midway?

After digging all the way down to the OpCode level, I had an aha moment that made me realize this system is truly a very precise logical architecture. Not just magic. Here are a few technical points I finally understood.

1. Bitcoin Does Have Smart Contracts (But They're Very Different)

At first I thought, "How can BTC run contracts with such a rigid language?" Turns out, Bitcoin uses its own language called Bitcoin Script. No complicated Virtual Machine like the EVM, just a stack-based script to create conditions for spending UTXOs.

LN can exist because these two main components work together:

OP_CHECKMULTISIG – This is used to lock funds in a 2-of-2 address. Funds inside a channel can't move unless you and your transaction counterparty both provide digital signatures together.
HTLC (Hash Time-Locked Contract) – This is the heart of routing. Your money is locked using a secret hash (OP_SHA256). The recipient can only pull the money if they have the secret key, otherwise the money automatically returns when time runs out (OP_CHECKLOCKTIMEVERIFY).

2. Channel Capacity Is Fixed, Can't Expand

This is what had me misunderstanding for quite a while. The balance inside a channel is absolutely static. If I open a channel with a capacity of 1 BTC from the start, then that path can only ever hold 1 BTC at most.

It's mathematically impossible to have a balance of 2 BTC inside a path that was only created to hold 1 BTC. It's like having a 1-liter glass—if you force 2 liters of water in, it'll spill. If the other party wants to send me more money, I have to free up space on my side first—either by sending some back to them or forwarding it through another channel.

3. The Reality of Routing: Balance Shifts That Make Your Head Spin

Now, if we act as an intermediate node (say, a transaction from C passes through me to B), what happens inside the machine is an atomic swap of balances.

When I forward 1 BTC from C to B, what really happens is that I release 1 BTC of my own in the channel towards B, but at the exact same moment, I receive 1 BTC from C in the channel towards C.

That's why sometimes the balance in one channel can look depleted and cause panic. But the money hasn't gone anywhere—my total wealth stays the same, it's just shifted location to the adjacent channel.

4. Inbound Liquidity: A Wall for New Users

This last technical fact is, in my opinion, the most crucial. If you just created a wallet, your balance is zero and you don't have any channels yet, you won't be able to receive LN transfers.

To receive money, you need what's called Inbound Liquidity. Someone else (or a third party/LSP) has to go to the trouble of locking up their BTC in a channel that points towards you. If there's no empty space prepared to receive money from outside, any transaction will bounce because the path is clogged from the get-go.

Conclusion

This exploration made me realize one thing: Lightning Network is deliberately designed as infrastructure for a circulation economy, not for casual transfers.

If you just want to move money from an exchange to a cold wallet and store it for years, using LN will actually cost you double fees. But if you want to build an application that needs thousands of microtransactions per second without spamming the main network, LN is the most sensible tool to use.