Readit Newsrobalni commented on CAPTCHAs are over (in ticketing) behind.pretix.eu/2025/05/... · Posted by u/pabs3
I feel like the only protection against AI in general, not just for tickets, is trust.
If I trust you, you can do whatever you want as long as I trust you.
If I don't trust you, you can do whatever you want; I will just block or ignore everything you do.
It's when we try to interact with random people that we get problems. Doing that will become less and less possible the more AI grows. We will have a future where trust is very important.
I just publicly released the first version of my
web+email+database combined server package that
I have been using myself for a while now for all
the different server based projects I have been
working on.
https://www.robalni.org/server/
I try to keep it as small and simple as possible while still being flexible and containing everything in one package that you need to write server applications. It also has no dependencies except for very common stuff like a standard C library and a Unix-like operating system.
> How fast they will get more could depend on the current value of their account, where the value could be calculated from the credits and the number of subscribers they have.
So are you then implicitly setting the price yourself because anyone who doesn't charge enough can't get more credits?
Suppose someone develops an app which takes hardly any effort to make -- it's a hundred lines of code -- but it does something common that everybody needs so if available for $0.01 it would have a hundred million users. Which would gross a million dollars and more than pay for the development of the simple app, so the developer is satisfied with that. But to do that you'd have to let them sell a hundred million subscriptions for $0.01 each.
Now let's go toward the other end of the spectrum. Some app which is specialized and requires a million dollars of developer time but only has a market of 10,000 customers. Those customers would pay $100 each for it, if they had to, but not if they can buy into the system somewhere else for $10 (or $0.01) instead.
In general, who is going to buy a fungible subscription for significantly more than it's available somewhere else? How do you handle the fact that the development cost of a thing isn't proportional to the number of people who use it?
> So are you then implicitly setting the price yourself because anyone who doesn't charge enough can't get more credits?
Everyone can get more credits. The idea is that when we think we need more subscriptions to sell, every developer would get a number of additional credits that is proportional to the number of credits they have (with active subscriptions converted to credits for the calculation).
> But to do that you'd have to let them sell a hundred million subscriptions for $0.01 each.
That would be very difficult for them to do since the number of subscirptions they can sell is limited by how many credits they have.
> Some app which is specialized and requires a million dollars of developer time but only has a market of 10,000 customers.
If you make software for only a few people and you need a lot of money then I don't think this system is for you. It is mostly for developers who make software for everybody.
- What do you expect open source developers to charge at minimum for access to the catalog in order to make this make sense to do at all?
If people subscribe once and access everything, it seems like they'd need to charge a lot to make it a worthwhile co-op to participate in. It feels like the amount they would have to charge would become pretty financially restrictive to access the code and not in the interests of someone who wanted to open source in the first place...
- How does this handle the scenario of a developer disappearing?
Does everyone who had access through that developer continue to have access?
It seems since payment processing is handled by individual developers, no longer would people have to pay for access to the whole catalog. Does this now mean over the long term you are handling an ever increase supply of people with access who do not pay but can transfer their access to others for free?
- How does this handle the scenario of developers with subscribers who are supposed to pay a reoccurring payment but have stopped?
Does the developer have the ability to remove access to the catalog from specific subscribers?
If the developers have the ability to remove subscribers at will, doesn't this disincentivize paying at all because paying gives you no security in your access you just bought? What is your plan to arbitrate this without access to primary payment information to confirm who is right?
- It seems like although decentralized, this approximates to the journal model but for code? Is this your intention?
> - What do you expect open source developers to charge at minimum for access to the catalog in order to make this make sense to do at all?
> If people subscribe once and access everything, it seems like they'd need to charge a lot to make it a worthwhile co-op to participate in.
I have thought about this a bit and yes, when this thing grows, the subscriptions will be worth more and more. I haven't really done any calculations though because it's really hard to know what things will be like. Anyway, let's try one:
Let's say there are 100 developers (individuals) and a developer wants $4000 per month. Then if we want a subscription to be $5 per month or maybe we could allow it to be $10, the number of subscribers per developer would have to be 100 * 4000 / 10 / 100 or just 4000/10 = 400. So I guess as long as the number of subscribers are a few hundreds times more than the number of developers (individuals), it could work.
> - How does this handle the scenario of a developer disappearing?
Interesting question; I have not thought about that. Developers register and unregister the subscriptions so hopefully they would unregister their subscriptions before they disappear. If they don't do that, it could be forced by the system but there would have to be rules about that then so everybody knows what will happen.
> Does the developer have the ability to remove access to the catalog from specific subscribers?
Yes, they can register and unregister subscriptions as much as they want.
> If the developers have the ability to remove subscribers at will, doesn't this disincentivize paying at all because paying gives you no security in your access you just bought? What is your plan to arbitrate this without access to primary payment information to confirm who is right?
That is between the buyer and the seller. If you buy something and you don't get what you bought, you would try to solve that with the seller. Of cource people can complain to 1Sub too and then maybe the other developers will lose trust in that developer and they can be kicked out.
> - It seems like although decentralized, this approximates to the journal model but for code? Is this your intention?
I have not thought much about the journal model but I can see how this is similar. My main vision has been tax that everyone who wants to be a citizen pays so that they then can enjoy things that are not sold directly to people.
> I don't know how different that would be though from if they sold physical products
I mean that's the literal point of this website, no? In the real world, a sale is a sale. Imagine going into BestBuy, leaving $100 at the front, telling the clerk to put it all into Sony (because Sony is 4 cool kidz) and then just grabbing a nVidia graphics card and Apple AirPods.
> One important thing here is that there is a limit to how many subscriptions one developer can sell.
Definitely interested in seeing how this will play out. Sounds like a recipe for either (a) a super cool, tightly nit community with high quality contributers who care about their software or (b) a dump for software which woudlnt cut it in the real world market.
>Also, they would probably sell the subscriptions for a higher price than other developers, since they can, which would mean that people who don't know about that person would buy from someone who is cheaper.
My game theory senses are tingling. Why would I incentivize people into buying other people's subscription while gaining access to my stuff?
>That means there has to be usage statistics collection in all software.
You could always implement it on your end, right? Could be download based, or whatever. A one time thingy.
> I mean that's the literal point of this website, no? In the real world, a sale is a sale. Imagine going into BestBuy, leaving $100 at the front, telling the clerk to put it all into Sony (because Sony is 4 cool kidz) and then just grabbing a nVidia graphics card and Apple AirPods.
Ok, I see what you mean now. I think the distribution of who gets the money in 1Sub would be similar to donations, with two remedies:
- The owner of the paywall that made you subscribe gets a 10 credits bonus as described in [0]. This will lead to more money to the people who make the things that you actually try to use.
- If someone is popular, they will either run out of subscriptions to sell, or they will sell them at a higher price. In either case that makes it possible for the less known developers to sell more subscriptions.
This product names crucial issues with how software development is currently monetized, and then offers an alternative that... solves absolutely none of these problems.
Optional extras like 'downloads or other resources' are presumably digital and therefore do not solve the problem - folks can still pirate it. If that's not the point, then it is a donation, in the simplified parlance of the first paragraph of 1sub.dev.
And this all from a company/effort that has such lofty goals that the html title of the page is 'a world where people pay for software'.
This (how do you monetize software development / how do we e.g. let FOSS developers capture more than the current 0.0000000001% of the value they create) is an incredibly difficult problem and this effort sounds like some naive newbie took 5 seconds to think about it and thought: Yeah let's fix things!
At the risk of sounding like a crotchety old fart: Hoo boy if it was that simple, it'd have been solved already.
Alternative plans that work a lot better:
* The NPM ecosystem has a ton of software-as-a-service offerings, e.g. where you can use their site to serve as online tool to e.g. make documentation, to have their site host that documentation, etc. I hate this model (you get nickel-and-dimed and both companies and open source developers alike don't usually like having 50 downstream service providers who, if they go down or have issues, require you having to explain to _your_ customers what's going wrong), but it solves the problems this site names (you can't pirate this, and you get something of value for your money in return).
* Tidelift tries to provide security assurances and support: The payers don't just 'donate', they pay to just be done with the security issues with FOSS dependencies: Tidelift gives you software that scans all your dev work for all your deps and which versions you are on, and tidelift ensures not just that there are no major security holes in those deps, but also that the authors of those deps have made some basic promises about maintaining it in trade for real consideration (namely: money). Github sponsors and the like are more or less barking up the same tree. These setups also solve an unstated problem 1sub.dev tries to solve, which is: You tend to use _a lot_ of software; if you have, say, 600 dependencies (not crazy in this modern age of software dev), and you want to individually set up a 'deal' with all of em, one person has a full time job as they will have to renew over 2 contracts __every working day__ assuming all your subscriptions are yearly.
* Microsoft and co do it as a package deal: You pay one fee for everything they offer and aggressively legally chase down anybody that pirates.
* patreon and co grease the wheels of the donation flow by making it simpler and allowing developers to give something that's hard to pirate: T-shirts and stickers, mentions in the 'about...' page and so on.
* Some developers of FOSS, as well as _many_ commercial outfits, will accept money in trade for priority support.
All of these models have issues. But at least they actually aim to solve the problems. This attempt doesn't even begin to tackle the actual issues, unless I'm missing something.
As a 1million+ user FOSS developer who maintains the library primarily based on privilege (I have enough income to work for the roughly minimum wage I currently get for it, though I could have earned vastly more if I worked for a commercial entity for those hours) - I'm aware that this is not a good situation, that you need to sort out your finances separately just to be a good FOSS author. But, I don't see how 1sub.dev is going to add much compared to what's already there (patreon, github sponsors, FOSS aggregators like apache and eclipse foundation, tidelift, etc).
> offers an alternative that... solves absolutely none of these problems.
Here is how 1sub solves or remedies the problems with the mentioned methods:
- Pay to download or for other services: With 1sub it will be more worth it because you don't just get access to that software or that service, you get access to the software and services of all developers who participate in this system.
- Accepting donations: While 1sub keeps some of the voluntary aspect of donations, you also get something for your money.
> folks can still pirate it
Yes, the point of this is not to make it impossible to do anything without a subscription. It just makes the difference in convenience between subscribing and not subscribing bigger since there are more things that you get or don't get depending on whether you subscribe.
> this effort sounds like some naive newbie took 5 seconds to think about
Interestingly I have thought about this for many years and no idea I have had before or any solution I have seen has felt as good as this one because they always fail in that the user doesn't have enough reason to pay. The main objective of this solution is to give the user more reason to pay.
By "people" are you excluding organizations such as governments, corporations etc?
> By "people" are you excluding organizations such as governments, corporations etc?
If you mean "people" as in "A world where people pay for software", then no.
I think companies, especially software companies, would like to subscribe in this system if it gets big because if they have dependencies that require subscriptions, they probably don't want anything to get in the way for their employees.
This is the kind of project that creates something from as little as possible, where the only things you need to get started are a very basic RISC-V assembler and a computer or emulator to run it on.
I don't have anything interesting to show yet because I just started yesterday, but one day I will show you.