awesome-selfhosted was very nice in a way that most other awesome repos are not. I think this was because it covered a pretty broad topic that didn't require a lot of skill to get started in.
Many awesome repos target such a narrow topic that the projects on the list would be early in search results anyway.
This seems like exaggeration, the paper seems to describe something more like abliteration, where Astra orthogonalized out activations related to undesired behavior.
This is obviously very different from the surface level claim that Astra can understand the weights of a completely unrelated model with enough detail to improve it in a manner that isn't just the latent space trickery we've been doing for years already.
It's not really exaggeration. It's doing something similar to abliteration, but more. First it finds the part of the weights that does a thing. But then the difference is, while abliteration deletes stuff, this is adding/changing things. It does this by doing semantic analysis of the weights, changing a little bit, see what happens. It's not super complex or advanced; it's essentially a form of statistical analysis and experiment.
This means we might not need to fine-tune with thousands of passes and tons of GPU. We could just tell a frontier model to edit some weights and iterate until there's better results. This could cut the cost of fine-tunes by 100x. Makes no difference to the normal end-user, but pretty huge improvement for LLM research and model tuning.
Given your reply, I was looking to read the paper. Apparently this blog post is what passes as their paper for now... I think I'll change my previous judgement and wait for a proper publication. I'm still not convinced by their claims, but maybe an eventual paper will spell it out more formally and convincingly instead of expecting readers to dig through all of their source code.
By the way, my understanding of abliteration is that it involves detecting the refusal direction and modifying the weights/activations away from that direction. I don't really see how that's "removing" in a way that's different from finding the "looping direction" and modifying the weights away from that.
I think the physical world comparisons should keep in mind the kind of data a lot of these systems (eg postgres) handle. It's more like securing a bank vault than locking a home's door.
Haven't bothered with DS4.1 personally but I've seen reports of running it with native weights on 4x DGX Sparks. Currently ~$30k but last month that setup was ~$20k.
Signal isn't anonymous. The server has access to your IP addresses and the server can at will build social graphs about the users.
Where Signal's safety in numbers happens is in normalization of end-to-end encryption. Users who want to protect their message content are not standing out from the rest, unlike in e.g. Telegram where the vendor sees with whom you enable secret chats.
Discovery is important and a hard problem, worth making some trade-offs for. Signal published a good blog post about this, including this passage:
> In order to turn the address book on a device into a social graph for Signal, the Signal client needs to be able to determine which of the device’s contacts are Signal users. [...] The obvious problem with this method is that the hash of a user identifier can almost always be inverted. [...] This method of contact discovery isn’t ideal because of these shortcomings, but at the very least the Signal service’s design does not depend on knowledge of a user’s social graph in order to function.
When they say "social graph for Signal", afaik they don't mean 'on Signal servers' but 'social graph on your phone'. It's a personal social graph that exists on the end-user device.
I don't remember how the hash issue is dealt with, however.
> Signal is not peer-to-peer. It is a centralized, client-server architecture.
It's not a P2P mesh, but Signal's servers are involved only for certain functions. I think communication tx is P2P - to send a message via server (used to hide sender IP address from onlookers and the recipient), you need to enable relaying. Possibly finding the recipient still relies on the server - if I want to send a P2P message to Abel, to what IP address do I send it?
The official signal.org blog post I linked does actually explain how it works. They write that the client sends parts of hashed phone numbers to Signal:
> The client transmits those truncated hashes to the service. The service does a lookup from a set of hashed registered users. The service returns the intersection of registered users. The obvious problem with this method is that the hash of a user identifier can almost always be inverted. Regardless of whether the identifier is a phone number, a user name, or an email address, the “keyspace” of all possible identifiers is too small.
Also: Signal messages are currently never P2P. They always pass through Signal servers, which see (but apparently not retain) your IP and timing metadata. The Signal WebRTC calls are partially peer-to-peer, that is what the relaying in the Signal settings panel is about.
>I think most messages are P2P unless the user activates relaying?
No they're all routed through the servers. It's only the calls that can be sent P2P and you have to opt in for that. The issue is that leaks your IP address to the contact who may not be trustworthy, so it's not used by default.
(Not to object the degoogeling, but:) To create a Signal account, you have to validate a phone number. So Signal is currently largly about privacy, not anonymity.
FWIW I wouldn't know why to message someone if I didn't know who they were. The same goes for them not knowing who I am. What would we even talk about?
The service operated by the incorporated 501c3 has full visibility into who else a user messages and when. This is not good for privacy.
What the non-low-value users are generally looking for is the option to not opt-in to discard anonymity with any potentially involved third parties such as server operators and network operators, and left at the discretion of the users solely.
Other systems have already solved this. One user can be not anonymous while another can choose to not opt-in to not be anonymous.
The users still know who the user on the other side is.
It seems he's responding to a question asking if he thinks people will be able to run local AI on their own computers. Not arguing on higher prices. So it comes off more as "people shouldn't get to have enough RAM to run local AI because it's an inefficient use of resources" rather than the capitalist "I can afford to pay more for RAM so I should get priority".
awesome-selfhosted was very nice in a way that most other awesome repos are not. I think this was because it covered a pretty broad topic that didn't require a lot of skill to get started in.
Many awesome repos target such a narrow topic that the projects on the list would be early in search results anyway.
reply