HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
portier
portier.github.io
HTML2016–2023
portier / portier.github.io

portier.github.io

Website for Portier, an email-based, passwordless authentication that you can host yourself.

6Distinct people
13Mentions
0Explicit recommenders
369GitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Website for Portier, an email-based, passwordless authentication that you can host yourself.

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 1:49:46 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year13 dated mentions

Observed mentions: 2016-01-12 21:03:10 UTC to 2023-10-12 15:35:51 UTC.

02468102016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 10 mentions; 0 submissions, 10 comments20162017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments20192020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2023

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC10010
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC202
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC000
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC000
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC000
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC000
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC000
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC101

What Hacker News says

13 sources
This looks great! I will definitely be taking a close look. Only thing I noticed with a quick try is that portier allows both a magic link and code for passwordless email login. Magic links are much more vulnerable to attack than codes because the email providers and anyone who may have access to your email can hijack your login from any location. I think it's fine to provide magic links but that choice should be the user's option when they enter their email, after warning them of the security implications. EDIT: They actually address this in their non-goals document[0] but disagree with the decision, since many users may not realize the tradeoffs. [0]: https://github.com/portier/portier.github.io/blob/main/Non-G...
In Show HN: Obligator – An OpenID Connect server for self-hosters
I'm not quite sure what you meant by "true decentralization", but even if some arbitrary ideal of maximum decentralization isn't possible on the current web, I think it's still worthwhile to strive for some degree of decentralization over none. And many technologies on the web do in fact offer varying degrees of decentralization through federation and interop, with email being the canonical example. And the use case you mentioned, for an arbitrary web page to ask the _user_ (because there's no reason why the browser absolutely needs to be an intermediary here. More on this in a bit) who it should be talking to in a decentralized manner, has been a solved problem for quite a while in the form of the WebFinger standard, whereby the user simply needs to provide an email address from a provider that implements the protocol on its domain (thou
Read the rest
gh it's not often used as a standalone protocol, it is actually quite well adopted as the discovery mechanism behind OpenID Connect, and I have used it in practice through the remoteStorage project: https://remotestorage.io/). Portier certainly doesn't claim to be trying to copy Persona's approach to authentication on the web exactly, and specifically it makes a conscious effort to avoid predicating the system's usefulness and any of its fundamental design considerations on native browser support (that's of course not to say that they would refuse to integrate with browsers if the opportunity does eventually present itself), a decision that stems from the lessons learned from the failures of Persona: https://github.com/portier/portier.github.io/blob/master/Non... At the end of the day, Portier strives to succeed Persona as an authentication mechanism, not as a browser-integrated authentication mechanism. And Facebook's current "holy grail" UX around authentication is living proof that you don't need explicit browser support to provide a great auth experience for the end-user. Whether Portier can be successful in replicating an experience like Facebook's while providing a useful degree of decentralization and user privacy as its mission statement declares remains to be seen, of course.
In Payment Request API
There's a recording of this keynote at https://www.youtube.com/watch?v=3dDGkLHOldw There's also a more in-the-weeds braindump of where Persona went wrong at https://github.com/portier/portier.github.io/blob/master/Oth... The actions we've seen from the executive branch this past week should underscore the importance of building decentralized alternatives to systems that forcibly route users through American corporations. Persona failed. Build something better.
In Designing for failure
Pretty much, yes. However, ideally you would not "Login with Portier", you would simply "Login". There is no need to mention the infrastructure used (and in our current modules, we simply generate a plain Login-Form without any branding). You also do not have to click on the link, you can enter the code which is in the email. Useful when mixing clients. And finally, when using a email provider with special support (currently: Gmail) you don't click on the email and also don't get one. You just login via Google-Sign-In and get then redirected to the site you are trying to login to. I hope we can support more providers (and custom domains soon). Not having to go into the emails is pretty nice. Edit: Also see https://github.com/portier/portier.github.io/blob/master/Des... for a more technical view on what happens here.
In Identity/Persona Shutdown Guidelines for Reliers
Persona was many things to many people -- arguably too many -- everyone from the old core team has a different idea of what features defined Persona. :) For me, it was the developer experience: trivial setup, email in/authentication out workflow, and no secrets to store in a database. Portier focuses narrowly on making that facet work well. Browser integration, identity aggregation, and privacy from users' own email providers are all non-goals for Portier: https://github.com/portier/portier.github.io/blob/master/Non... That said, I'd love to ask what you found compelling about Persona's promise of browser integration. The privacy aspects? User experience? The finality of a standard successor to HTTP Basic / Digest authentication? Something else entirely?
In Identity/Persona Shutdown Guidelines for Reliers
Yes. It's multi-provider authentication as a service. I think this matters, since it means I can run a single instance to support all of my projects, regardless of language, because everything speaks HTTP. I don't have to grapple with OmniAuth for Ruby, AllAuth for Python, Passwordless for Node, and lord knows what for experiments in Clojure, Elixir, and Rust. I don't have to set up outbound email, register social API keys, and design a hybrid login form for each of those projects, either. Set up Portier once, and I'm done. I've written more about Persona's failings and virtues at https://github.com/portier/portier.github.io/blob/master/Oth..., which might better explain why I view this as a successor. As to Identity Providers... as long as websites utilize email addresses as a way of identifying accounts and resetting passwords, we're in
Read the rest
the same place. Portier makes this no worse. I sympathize with the notion that identity should not be leased from a third party, but I don't know how to solve that. Blockchains? I'd encourage others to pursue that future while Portier tries to carve out an ephemeral but useful island in the present.
In Portier – An email-based, passwordless authentication service
I read that you're not planning to integrate with Facebook[1], but what about other providers, if they allow you to request access to almost nothing? Perhaps, for example, allowing people to use <their-name>@github.com would prompt them with a GitHub OAuth screen and identify them. Why not? I see, it is not a valid email. Maybe there should be a Portier fork that implemented stuff like that, though. [1]: https://github.com/portier/portier.github.io/blob/master/Non...
In Portier – An email-based, passwordless authentication service

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.