To clarify some terms:
Forward secrecy: a key compromise at a given point in time, should not reveal content from previous conversations.
First, the discussion below describes features designed and planned, but not yet implemented in Semaphor 1.0.x. Accommodations for these features already exist in the Semaphor data structures, but there is presently no implementation code to make use of them. In Semaphor 1.0.x, there is no configurable "retention policy" for channels and conversations (all content is retained forever.) Without limiting retention, there's also no context to implement forward secrecy.
Next, below we're referring to Semaphor's content layer. At the transport layer Semaphor's protocol uses Golang's implementation crypto/tls with pinned certificates and forward secrecy, so a network level attacker capturing traffic does not later have the opportunity to decrypt that captured traffic based on a future TLS compromise.
In the near future, Semaphor will support configurable retention policy, allowing you to specify that channels and conversation have retention such as "keep message for the last 30 days" and/or "keep the last 1000 messages." This is similar to the posture many institutions adopt for email retention policy.
This means that when a new member is added to a channel, instead of receiving all the history, the new member only receives the history back to a particular point in time. Having a limited content retention policy in place creates the opportunity for a form of future/forward secrecy with a rolling window.
When a retention policy is in place, Semaphor will create new channel session keys (for message content) mirroring the retention policy. For example, if the retention policy is 10 days, then every day** a new temporary session key is created for the channel and shared with the channel members. Also each day the oldest session key is purged (along with the oldest messages) by all devices and the server.
Since historical messages and the session keys to encrypt them are both being rotated out, a compromise reveals previous content limited to the retention policy.
** Actually session keys are created lazily, on demand. I.e. a new temporary session key is created for a given day at the time the first message is sent that day. If no messages are sent, nothing happens.