Hey nostr:npub16g4umvwj2pduqc8kt2rv6heq2vhvtulyrsr2a20d4suldwnkl4hquekv4h , what's this? This is one of my first prompts at ppq.ai. Deleted a long time ago. Yesterday they showed up about 50 times again in my history. Shouldn't something that's deleted actually stay deleted in a privacy-friendly service?
It's must be self-aware 🤖
Yes it all should stay deleted and that fact that it is popping up again is definitely a bad thing and shows we aren't properly deleting stuff. We have been struggling with our server side accounts (supabase) in the last days trying to debug a lot. This particular error seems to be happening when the client side tries to sync with the server side and vice versa. Just to be clear, you have a server side account with us (you have an email-attached account), correct?
We are on it and thanks for reporting.
Actually according to my CTO we fixed this yesterday. Once you delete these they should be deleted for good and we should be properly and permanantly deleting them on server side now.
I'm not very convinced to be honest.
We're doing our best to deliver on our promises. Bugs happen. If you want to use us without an account you are free to do so. Or you are also free to use another service if you no longer trust us. We make mistakes. Period.
We are also ideating on a lot of other ways we can provably deliver ultimate privacy such as storing user chats encrypted on nostr relays or other some such ideas, but those are steeper engineering challenges that will take time.
If you have any other ideas on how we can architect things better we are all ears.
To further explain what we think happened... We believe there was a bug such that when a user returned to PPQ after a previous session, it appeared to the user that they were logged in, but in actuality their login token expired. However, because we store user convos both client and server side, the user was still seeing the client side version of their chats as if nothing was wrong. Then, if that user deleted a particular chat, it successfully deleted it client side, but because they were not logged in anymore, the delete action never made it to the server side and thats why it persisted thereafter.
So why did your old chat just spray onto your screen again in duplicate? When you logged in again, it tried to retrieve any chats on the server (which were not deleted because of the aforementioned issue) and when it did, a react hook fired too many times causing the duplication (another bug we've now hopefully fixed).
Hope this helps you understand the situation a bit more.
its trying to tell you something, its screaming from the void
nostr:nprofile1qqs02f70juxwyc88gfsjzjlkzt50wkjemvvrtmt7gpfnymplvh3r9mspzamhxue69uhhyetvv9ujumn0wd68ytnzv9hxgtcpzamhxue69uhhyetvv9ujuurjd9kkzmpwdejhgtcpz9mhxue69uhkummnw3ezuamfdejj73r4387, have you considered using OTRTA?
It's an e-cash based nostr client that you can use instead of ppq, but you can self host it.
The client has an integrated e-cash wallet and it puts e-cash notes in the HTTP request that goes to the LLM aggregator and receives change in the HTTP response from the aggregator. No identity required...
I have been using it since before pizza day and I haven't faced any issues so far.
nostr:nprofile1qqs02f70juxwyc88gfsjzjlkzt50wkjemvvrtmt7gpfnymplvh3r9mspzamhxue69uhhyetvv9ujumn0wd68ytnzv9hxgtcpzamhxue69uhhyetvv9ujuurjd9kkzmpwdejhgtcpz9mhxue69uhkummnw3ezuamfdejj73r4387
Is this somehow based on Ollama/OpenWeb UI? Kinda looks like it. I've heard about it before, but I'm not very familiar with ecash. Can you also top it up with Lightning?
Ya the e-cash wallet can be topped up via lightning. The merchant that processes the requests essentially does the same thing as PPQ, but this merchant takes e-cash notes rather than requiring that the customer has an API key (ie. account/identity).
nostr:nprofile1qqszyfx6zltkhwrl73s3amerjck6qnc4f2dmueqn2h7tv3ywxkwjyzsprpmhxue69uhkummnw3ezucmgv95k6cfwd9hxvme03jvryw can provide support
nostr:nprofile1qqsdy27dk8f9qk7qvrm94pkdtus9xtk970jpcp4w48k6cw0khfm06mspp4mhxue69uhkummn9ekx7mqpzemhxue69uhhyetvv9ujuurjd9kkzmpwdejhgqg4waehxw309ahx7um5wghx77r5wghxgetk9uj8qus8 have you considered using the tooling that nostr:nprofile1qqszyfx6zltkhwrl73s3amerjck6qnc4f2dmueqn2h7tv3ywxkwjyzsprpmhxue69uhkummnw3ezucmgv95k6cfwd9hxvme03jvryw uses to serve customers without API keys?
I'm sure he would be happy to help you set it up..
ecash is something we've been looking at yes but we hadn't seen this implementation yet. Thanks.
Users are not required to have account/balance by their provider they could switch provider instantly without asking for refund..
when user sends a request an ecash token is created and added to the request, providers forward the request to an ai provider (like openai) get paid with the token provided and return change (if any) .. Basically the user has always a new identity
