emurlin

This is a browser-based JS benchmarking tool I've been working on for the past weeks, unsatisfied with the alternatives that are out there. The goal is / was supporting most features one would need (like NPM or JSR packages), setup and teardown code, seamless support for async code, etc. and at the same time present a report with not just raw speed (as most tools do) but with useful statistics.

The project is split into two parts, one which is this ready-to-use web UI (obviously, useful for testing in the browser), but also a minimal library that can orchestrate the tests and produce a report (with some nice CLI-based reporters too).

In this case, it's based on a per-user secret key and AES-256, which with some careful key and IV-derivation, allows you to have a deterministic (and reversible) address for any given domain name. The basic principle (applied to ids, which extends to domain names) is in this blog post: https://apeleg.com/blog/posts/2023/03/30/enumeration-timing-...

If you're willing / able to sacrifice reversibility, a more orthodox approach can be hash (or *MAC) based. For example, SHA-256(secret + domain-name). However, a key point of this project is attribution, to avoid the need of storing a large set of pre-generated addresses, for portability and for easy reverse aliases.

In terms of the actual SMTP bits, I'm currently relying on Cloudflare workers for receiving and delivering (just a nice and gratis API); however, extensibility within reason is a goal (in scope: provider-agnostic API; very probably not in scope: an SMTP client / server).

Most of my time goes to Group Income (https://groupincome.org) / Shelter (https://shelterprotocol.net), a protocol and platform for building rich decentralised rich (web) applications with end-to-end-encryption. The idea is building the tech for an experience rivaling or surpassing that of siloed apps but with a focus on user and data autonomy.

The rest of my time goes into a few personal projects, most with no public URL yet.

  * An IndieAuth provider based on WebAuthn, the idea being that instead of relying on delegating authentication, it could be handled directly using, e.g., U2F keys or a device.
  * A temporary e-mail address provider with deterministic addresses for attribution.
  * A self-service menu / ordering service
  * An E2EE document signing solution

   * An HTTP media type negotiator (https://github.com/ApelegHQ/ts-http-media-type-negotiator) -- negotiate based on accept headers. This was because I couldn't find a negotiator that correctly parsed headers.
   * A JS sandbox (https://github.com/ApelegHQ/lot) -- Tried to implement something lightweight yet functional
   * A MIME multipart encoder and decoder (https://github.com/ApelegHQ/ts-multipart-parser) -- Attempt at a lightweight, general and spec-correct parser
   * A lightweight ASN.1 DER encoder (https://github.com/ApelegHQ/ts-asn1-der), meant to be used with its sister project (https://github.com/ApelegHQ/ts-cms-classes) --- Part of the document signing project

    * A web-based self-contained encryption/decryption tool (https://github.com/ApelegHQ/ts-cms-ep-sfx) --- Created to easily share files with maximum compatibility (ZIP archive inside a CMS payload) and minimum requirements.

https://riv.ar

At the time, it's mostly just a web CV (with some effort put into implementing RDFa and microformats). The intent is adding a blog section too.

SEEKING WORK | Norway | Remote | Contract (full-time or part-time)

Experienced software engineer specialising in backend development with a proven track record. Over ten years of industry experience, delivering exceptional results to drive projects forward.

What sets me apart:

- Broad expertise: Projects and technologies include data integration, Intel SGX, consensus protocols, REST APIs, and web development. Proficient in C, C++, CSS, Docker, ES6+, express.js, Java, JavaScript, Kotlin, LDAP, Linux, Neo4j, nginx, Node.js, PHP, PL/SQL, Postfix, React, TypeScript, Xen, and (X)HTML5, I possess a versatile skill set.

Why choose me:

- Strong problem-solving skills: Thrive on challenging problems, finding creative solutions. Excel in optimizing performance, designing scalable architectures and resolving complex technical issues.

Expertise in Identity and Access Management (IAM), security, and data integration. Deep understanding and practical experience to deliver secure and seamless solutions. Open to exploring new challenges and technologies beyond these areas.

Available for full-time, part-time, and consulting engagements. Let's connect and discuss how I can contribute to your success.

Location: Trøndelag, Norway

Remote: Yes (remote only, unless within Trøndelag or occasional meetups within Scandinavia)

Willing to relocate: No

Résumé/CV: https://riv.ar/curriculum-vitae/

Email: hn-u5cgNWJM（-ａｔ-）protonmail.com

GitHub: https://github.com/corrideat, https://github.com/ApelegHQ

SEEKING WORK | Norway | Remote | Contract (full-time or part-time)

Experienced software engineer specialising in backend development with a proven track record. Over ten years of industry experience, delivering exceptional results to drive projects forward.

What sets me apart:

- Broad expertise: Projects and technologies include data integration, Intel SGX, consensus protocols, REST APIs, and web development. Proficient in C, C++, CSS, Docker, ES6+, express.js, Java, JavaScript, Kotlin, LDAP, Linux, Neo4j, nginx, Node.js, PHP, PL/SQL, Postfix, React, TypeScript, Xen, and (X)HTML5, I possess a versatile skill set.

Why choose me:

- Strong problem-solving skills: Thrive on challenging problems, finding creative solutions. Excel in optimizing performance, designing scalable architectures and resolving complex technical issues.

Expertise in Identity and Access Management (IAM), security, and data integration. Deep understanding and practical experience to deliver secure and seamless solutions. Open to exploring new challenges and technologies beyond these areas.

Available for full-time, part-time, and consulting engagements. Let's connect and discuss how I can contribute to your success.

Location: Trøndelag, Norway

Remote: Yes (remote only, unless within Trøndelag or occasional meetups within Scandinavia)

Willing to relocate: No

Résumé/CV: https://riv.ar/curriculum-vitae/

Email: hn-u5cgNWJM（-ａｔ-）protonmail.com

GitHub: https://github.com/corrideat, https://github.com/ApelegHQ

  > Many valuable, high-quality pieces of content that people would find useful never make it into Google's index.

Anecdotally, this observation comes from searching for any term and seeing the results: they are usually similar-looking plausible-looking-but-actually-low-quality results that seem to follow the same or similar structure and have the same content. This does indeed limit the diversity and depth of information, but I'm not so sure it reduces spam, as these low-quality sites seem to be as prevalent as ever before, if not more.

From experience writing articles to a small tech blog, this means that it's quite difficult to get well-researched articles to rank well, even if they're indexed.

For example, I've written an article on how to block hotlinking (I've just checked, and Google says it's indexed). If you search for this, my article on a not-so-well-known blog is nowhere to be found(*)(**), and this is somewhat expected, for a myriad of reasons. The problem isn't that my post doesn't rank, but rather that none of the top-ranking (or even not-so-top-ranking) results are wrong. They are either about how to do this on cPanel or whatever, which is ineffective (but granted, could be what people are looking for), or instructions using the `Referer` header, which is ineffective.

These days, browsers offer headers like `Cross-Origin-Resource-Policy` which can completely solve the particular issue of hotlinking, unlike `Referer` which is easily bypassed using `referrerpolicy="no-referrer"`. However, because most 'authorities' seem to be wrong on this issue, the correct result isn't displayed, because it's a hard problem to solve algorithmically (or even manually).

(*) This doesn't affect just Google, though.

(**) Because it's indexed, adding the right keywords (which you wouldn't do in this case unless you already knew the answer) does bring it up, although from federated high-authority sites instead of the original canonical source.

Interesting approach! As an author of another JS sandbox library[1] that uses workers for isolation plus some JS environment sanitisation techniques, I think that interpreting JS (so, JS-in-JS, or as in this case, JS-in-WASM) gives you the highest level of isolation, and also doesn't directly expose you to bugs in the host JS virtual machine itself. Since you're targeting Node, this is perhaps even more important because (some newer developments notwithstanding) Node.js doesn't really seem to have been designed with isolation and sandboxing in mind (unlike, say, Deno).

From the API, I don't see if `createRuntime` allows you to define calls to the host environment (other than for `fetch`). This would be quite a useful feature, especially because you could use it to restrict communication with the outside world in a controlled way, without it being an all-or-nothing proposition.

Likewise, it doesn't seem to support the browser (at least, running a quick check with esm.sh). I think that that could be a useful feature too.

I'll run some tests as I'm curious what the overhead is in this case, but like I said, this sounds like a pretty solid approach.

[1] @exact-realty/lot

Exploring Proof of Work (PoW) as a substitute for CAPTCHAs is an interesting idea (PoW was originally conceived as a spam deterrent, after all), and one that I have considered (and use) in some web properties I manage. Not only does it obviate 'trusted' third parties, but it also has the potential to reduce the risk of accessibility issues often associated with traditional CAPTCHA. It also seems like a solution that scales nicely, as each 'proof' is made by the client and verification is cheap, and like a solution that finally ends the arms race against malicious traffic by bypassing the need to 'prove humanity'.

However, it's one of those solutions that look good on paper, but upon close inspection break down entirely or come with rather substantial tradeoffs. Ignore the environmental discussion about energy consumption for a moment, and let's face the reality that computational power is ridiculously inexpensive.

As a thought exercise, imagine you're trying to use PoW to ward off spammers (or the attack du jour), and you decide that a 1-cent expenditure on computation would be a sufficient deterrent. Let's say that renting a server costs $100/month (a bit on the higher end), or 0.004 cents per second.

So, if you wanted a PoW system that would cost the spammer 1 cent, you'd need to come up with a computational task that takes about 250 seconds, or over 4 minutes, to solve. That kind of latency just isn't practical in real-world applications. And that ignores that 1 cent is probably a ridiculously low price for protecting anything valuable.

Of course, you may consider this as an alternative to regular CAPTCHA services. A quick search gives me that this costs something like $3 for 1000 CAPTCHAs solved, or 0.3 cents per CAPTCHA. This changes the above calculation to about 1 minute of compute, which still seems rather unacceptable considering that you might, e.g., drain your users' battery.

So, overall, while I'd like for something like this to work, it probably only acts as a deterrent against attackers not running a full browser and who also aren't targeting you in particular.

Indeed, although undocumented, this is implemented and is a PAKE variant ([1] and [2]).

The way that it works, at a high level, is similar to how SRP works. Two random salts are generated (let's say, A and B), where A is used for authentication (and hence public) and B is used for deriving the other cryptographic keys.

When you authenticate, you retrieve A and then you prove to the server that you know what scrypt(A, password) is. At this point, the server provides you with B, and you can use this information to derive scrypt(B, password), which in turn you use to derive other cryptographic keys.

It being an oblivious password store, there are other steps taken to make the protocol stateless (from the perspective of the server) and to make parties commit to random values used so that runs of the protocol cannot be replayed.

but the password database itself is still vulnerable to dictionary attacks once it’s stolen

This is correct, and I'm not sure there are good ways to prevent this or equivalent scenarios from occurring. Therefore, you should see this as an additional layer on top of your already secure password and not as a substitute for a secure password.

The reason for having this mechanism rather than not having it is to protect your password from brute-forcing by the public at large, in a scenario where the server operator is semi-trusted. Without this implementation, you have three alternatives: (1) Forego passwords entirely; (2) make the salted password 'public', along with the salt, which is all the information you need to brute-force it or (3) make more "normal" authentication flows without PAKE, in which case you need to trust the server even more. If you insist on using passwords, this is a compromise solution between (2) and (3), i.e., between anyone can break it and trust the server entirely.

[1] <https://github.com/okTurtles/group-income/blob/e2e-protocol/...>

[2] <https://github.com/okTurtles/group-income/blob/e2e-protocol/...>

What do you mean by replacing trust with crypto? Like in 'code is law'? If so, yeah, you can't replace one thing with the other because they're fundamentally different things that may only overlap in certain areas.

But on a broader scale, I don't see what in cryptography makes power inherently more concentrated. Crypto is just a way for enforcing certain trust relations that have already been established or agreed upon. Just like you can use crypto to help centralise power (e.g., allowing you to only run signed applications that can only show signed content), you can use crypto to help decentralise power with tools for confidentially presenting content and allowing you to vet your applications haven't been tampered with.

In both cases the underlying technology has many common components, and what changes is the use you make of it.

you cant compute yourself out of a broken world.

Most certainly not, but surely you can build better tools with the aspiration of facilitating certain goals, can't you? It's not the tools in or by themselves that will improve (or worsen) the world, rather something at your disposal to pursue your goals.

the myth that the computer will lead to a better, more equal society

Agreed that it won't. But, IMO, the strength of Shelter is that it covers a niche that many other systems (blockchain-y or otherwise) don't, which is data autonomy and confidentiality. Most popular web apps today are centralised silos that don't give you privacy from the operator, and those that aim for federation often also don't give you much privacy either.

Now, it can be that those factors are not important for the specific thing you're developing, and that's fine. But, if they are, having an existing framework to build on top of can give you a head start (even indirectly, by showing you what works or doesn't).

Disclaimer: I'm involved in the development of Shelter. All opinions are my own.

I can't seem to find an old article written on the early days of OAuth 2.0, praising OAuth 1.0a, because among other things it signed the URI parameters and because unlike OAuth 2.0 Bearer tokens, OAuth 1.0a didn't require sending credentials in the clear (this was at a time when HTTPS wasn't quite as ubiquitous, and OAuth 2.0 pretty requires TLS to be used securely).

As someone often working with OAuth 2.0 flows, I enjoyed the article and think that it raises many good points. I'd also say that many of them come from things that affect _any_ system solving a problem similar to OAuth 2.0, because authorisation is hard to get right, or from extensions to the protocol that really aren't OAuth 2.0's fault (like the `realmID` parameter, obviously added to make the life of those API developers easier at the expense of those actually trying to integrate with their systems).

To me though, I wholeheartedly agree with 'Problem 1: The OAuth standard is just too big and complex' and 'Problem 2: Everybody’s OAuth is different in subtle ways'. OAuth 2.0 is more of a framework or metastandard, and no API implementation uses all parts of it because they simply are not relevant to that API or use case. This alone makes it quite hard to 'simply use OAuth' for an integration, because a big part of the job is figuring out which parts are used and in which ways, even if everything is done per the RFCs.

By contrast, OAuth 1.0a was comparatively much simpler and focused on a more narrow problem. OAuth 2.0 allows you to convert a SAML claim from one provider into an OAuth 2.0 token for a different provider to then delegate permissions conditionally to another actor for a particular action on yet another API.

Are we better off with OAuth 2.0? I say yes, because figuring out the differences between providers is probably easier than realising a hundred completely different implementations that have very different ideas of what an authorisation or delegation flow should look like. I think that one can learn to reason about OAuth 2.0 and then apply this logic to integration jobs with slightly less cognitive load than a completely bespoke solution.

At the same time, I think something sorely needed is something like OAuth 2.0 profiles that standardise the features used to integrate with OAuth 2.0. Probably most social media sites have similar requirements, most auth-as-a-service have similar requirements and so on. Having a common subset of features and decisions for common use cases and scenarios would IMO greatly simplify integration tasks and, paired with choosing a good library, make it indeed possible to integrate with a random service in under an hour.

The thing is that some of that was the spirit of older standards like OAuth 1.0a and OpenID (not to be confused with the newer OpenID Connect, which is OAuth 2.0-based), and the world seems to have moved away from that, probably because of the flexibility that OAuth 2.0 affords and the want to tightly control authorisation and external integrations.

I was thinking the same, but according to [1] some parameters like the hostname are hard-coded. So, that might be why you need to make the code public on GitHub (although still, technically you can still comply with the AGPL with a private repository).

[1] https://news.ycombinator.com/item?id=34508935

Indeed you can. I've had similar issues before (a site scraping content, though apparently from dev.to instead of my own domain and a YouTube channel making a 'video' with text and TTS from a post).

In the first case, I sent a DMCA to Google & Bing as well as to Cloudflare. Cloudflare responds by giving the name of the actual host, and I sent another DMCA to that host (they were US based, otherwise YMMV). The content was delisted (not the site, even though it was made up entirely of verbatim scraped content) from search engines and from the site.

Bottom line is you can send a DMCA notice to search engines and it appears to be effective. Actually, in case search engines demote sites like this in some way, I would send the DMCA notice to search engines _first_, because if the content gets removed from the original site they may not be able to verify the duplicate content.

I'd guess there's a race condition that causes the eyes to end up closed, because the 'delay' can sometimes be less than 150 and `blink` gets called while it's already executing (so `src` ends up being the blink version). A simple fix would be adding `await` to `blink()` if that's the case!

BTW, I made a vanilla JS version for fun, without jQuery or promises (untested)

  function blinktimer() {
      var avatar = document.querySelector(" .avatar ");
      var srcBlink = '/images/dadi-avatar_blink.png';
      var blink = function() {
        console.log("BLINK!");
        var srcOpen = avatar.src;
        avatar.src = srcBlink;
        setTimeout(function() {
                avatar.src = srcOpen;
                var delay = (Math.random() * 11000) | 0;
                setTimeout(blink, delay);
        }, 150);
      }
      var delay = (Math.random() * 11000) | 0;
      setTimeout(blink, delay);
  }

I think what I will likely do is {"scheme": "business:DK:CRV", "id": "123456789"} to refer to a Danish business in the CRV registry, and {"scheme": "business:NO:ORG", "id": ..} for a corresponding Norwegian business, and {"scheme": "nin:DE", "id": "..."} for a German citizen. (This is to refer to "a legal entity that can own something and that we have an agreement with")

Yeah, I think in any case you need to end up with your own solution (personal ID numbers are especially messy because a single person might have none or many). However, may I suggest a less verbose format? Parsing JSON looks overkill for the purposes of IDs (I'm assuming this is something you'd want to index)

For example, you could go with `urn:<some prefix for your org>:<your app ID>:id:<entity type>:<ISO CC>:<ID type>:<ID number>`

There are URN namespaces that refer to other namespaces (notably OIDs) and many things can indeed be specified. For example:

  * A UK company: `urn:oid:1.2.826.0.1.<company number>`
  * IBAN account: `urn:oid:1.0.13616:<account>` (note that there's also a URI scheme for this)
  * A publication: `urn:isbn:<ISBN number>`

However, the reason URNs don't have much traction is that, because they require interpretation to be meaningful, using 'correct' URNs is of little or no benefit. Besides purism, does your app _really_ benefit from using something like `urn:isbn:123` instead of `isbn:123`, `isbn-123` or simply `123`? In all cases you need additional logic to interpret the data. An advantage may be when interacting with other systems, but most likely you'll need to transform your data anyhow.

Adding to the issue above, another issue is that there might be several 'correct' URNs for the same external entity. For example, `urn:iso:std:iso:3166:USA`, `urn:oid:2.16.840` and `urn:oid:1.2.840` all refer to the same country (as well as `urn:uuid:7f5f8e3e-6f89-4903-a9c1-0fdb030ddb13`, that I just made up).

1. Ory Kratos provides session-based authentication and user management. > 2. Ory Hydra is a self-managed server that secures access to your applications and APIs with OAuth 2.0 and OpenID Connect.

Sounds about right.

1. Bugs around traits meant we had issues around password change, password recovery and email change/reverifications for our use-case

Can't comment much on these as I haven't experienced those issues, but I'm curious to hear what the issues were.

2. Lack of documentation prevented us making progress on 2FA/WebAuthn

Things have moved on in the last months, and the 2FA/WebAuthn implementation seems more mature and documented.

3. Bearer token/Oauth consent flow wasn't available without a lot of work because Kratos and Hydra are not "integrated" [1]. Someone shows how they rolled their own integration [2].

That's right, sadly there's no 'integration' available officially. There've been at least two pull requests (I made one of them) to add Hydra integration to the official demo Kratos UI, which for different reasons weren't merged. I'm not sure I'd say it's so much work (essentially, it's getting the existing Kratos session and translating those into a Hydra session, with a couple of API calls), but it's not something very well documented (or at all) and you're left to figure it out by yourself from the API documentation. I hope that integration between the two is improved, at least with an official demo showcasing the calls needed in order and with the right parameters.

That'd depend on the implementation details. Within the Ory ecosystem, you have Kratos (identity management), Hydra (OAuth2 & OIDC server, dealing mostly with token issuance, not so much with identities, which you have to provide externally) and Oathkeeper (API gateway).

For browser use cases, the recommended approach with Kratos is to use cookies (which means that Kratos need to follow the same site rules for the site it's set up for). Since Kratos is separate from the system you're trying to provide authentication for, you need some kind of token issuance, but you can make it as short-lived as you'd like. Within the ecosystem, you'd use Oathkeeper to transparently convert a Kratos cookie to an ID token, but this token can be generated with an arbitrarily short lifespan, and so you can revoke sessions with immediate or almost immediate effect.

Where things get a bit more complicated are if you exchanged that 'local' Kratos token for a different sort of token, like an OAuth2 bearer token (which may give access to external systems). In this case, ending the Kratos session doesn't immediately revoke those other tokens. You need to either accept that tokens might outlive the actual session they originated from (sometimes you might even _want_ this, for instance in an asynchronous service), or else keep track of these other tokens and revoke them individually.

If you're using Hydra for these other tokens, you can either use JWT or 'opaque' tokens. With JWT, you have the issue you mention that the token itself has some state that might become stale, but if you're using 'opaque' tokens, you don't get any claims from the token itself and you're supposed to get these from a separate introspection endpoint. You can make these introspection requests as often as you'd want, like for Kratos cookies above. Hence, if you revoke the session in Hydra (or whichever other OAuth2 server you're using) and you're validating tokens, you can revoke sessions almost immediately, with some overhead that comes with splitting a system into separate ones.

Just to clarify, do you mean I can work outside US jurisdiction, if I am a CEO of the LLC? I think this is my only question.

That's a question for an attorney in the area, but AFAIK, yes. What you can't do is work _in_ the US without proper authorisation from DHS.

No amount of reporting or cost burden is an issue.

If you yourself are in the EU (or even if you're not but your clients will be), you should _also_ talk to an EU attorney. It's likely you'll have to register in some way in the EU.

EDIT: No matter where you are (EU or not EU), it's rather likely that your local jurisdiction requires a registration of sorts if you're conducting business in/from their soil, with similar requirements as local businesses.

It sounds like you should really talk to an attorney or two, especially after reading you want to go into a highly regulated field also.

IANAL and not a startup founder who incorporated in the US, but answering as someone with some general knowledge on the subject and some experience incorporating on different jurisdictions (with the usual disclaimer that this no legal or tax advice).

Generally, you can 'incorporate' in the US as a non-US person. I put that in quotes because LLCs are not technically corporations (US LLCs are 'unincorporated associations') so normally the term used is 'organized' or some such. You can also incorporate proper, having a C corporation in the US. As a non US person, what you cannot do is be a shareholder of an S corporation, which is a special type of corporation that is pass-through for tax purposes (in short, meaning that the shareholders pay tax directly instead of the corporation itself being taxes).

If you want to go down this path, it's good you're looking for a good lawyer, as they can advise you on the best way going forward. That said, there are many online formation services that take care of the paperwork for you for some nominal fee (say between $200-$500), and some jurisdictions that are popular for non-residents are Delaware Nevada and Florida. As far as I know, for Delaware this is partly because of some perceived tax benefit, plus it being a place with a good reputation for doing business.

For question number 2, if you'll be working from outside the US, I don't see how it can be an immediate problem, since immigration laws that restrict you from working usually would apply when you're in US soil. As far as I know, there's no restriction on working from abroad, so long as you otherwise follow the law. You could probably even be an employee of your LLC in your local jurisdiction.

You don't say why you want to incorporate in the US and maybe you have good reasons for this. However, some of the negatives are that you'll likely complicate things for yourself, as now you'll have to report to the US authorities (taxes, etc.) in addition to to your local jurisdiction, you'll likely need US and XX accountants, etc. Plus, LLCs are sometimes problematic from outside the US, because they're not really corporations, which from what I hear can cause issues with things like opening local bank accounts, registering with local authorities, etc.

Under transfer pricing rules, you're likely not going to get any tax benefits from operating a US entity, and you could if fact end up double- (or triple-)taxed, depending on where you are and where your clients are and the tax treaties between all those places.

Since you say you're not in the US and mention EU-clients, maybe consider incorporating in some EU state instead?

Got it (although it doesn't seem to work on MSIE), which I guess is fine. However, it reminded me of https://www.sitepoint.com/community/t/i-found-a-way-to-hide-....

SEEKING WORK | Remote | Part-time

I am a software engineer with over eight years of experience and a background in information security. I prefer backend work, and I have experience in a variety of projects and technologies, including data integration, Intel SGX, consensus protocols, REST APIs and web development. I am familiar with agile methodologies, and I have worked as scrum master and in DevOps roles.

I learn things quickly, greatly enjoy solving challenging problems and pride myself in delivering custom solutions that address your needs in the best possible way, from their design and architecture to their day-to-day performance.

In addition to doing development, I believe I am the most helpful with system design and architecture, including APIs; coaching and mentoring and code reviews.

Technologies: C, C++, CSS (especially legacy browsers), Docker, ES6+, express.js, Intel SGX, Java, JavaScript, Kotlin, LDAP, Linux, Neo4j, nginx, Node.js, PHP, PL/SQL, Postfix, TypeScript, Xen, (X)HTML5 and more.

I am available for part-time engagements and contract work.

Location: Norway

Remote: Yes (remote only)

Willing to relocate: Not at the moment

Résumé/CV: https://dl.exactrealty.co.uk/cv/20210307_CV_Vieitez_Parra.pd...

Email: 51gcj6cm {-at-} anonaddy.me

GitHub: https://github.com/corrideat