All FemtoStar services are delivered on a best-effort basis, at the highest speed technically feasible with the user's hardware and with network traffic at that time. We do not impose artificial restrictions on bandwidth. The flipside of this is that, while we do not limit you to a maximum speed, we cannot guarantee you will always get one particular speed either - getting the maximum possible at all times means that, unlike a service where you are constantly limited to a certain bandwidth even when more is possible, FemtoStar performance will vary. Performance at some times being lower than at some others should be expected.

FemtoStar service is paid for in terms of the amount of beam time a session consumes - that is, how long the satellite needs to spend using one of its beams to transmit data for that session. This is not the same as the amount of time a user stays connected to the network - because the beam must also serve other users and any particular user's terminal is unlikely to be consuming the full throughput of its link at all times, a connected terminal consumes much less beam time than the amount of time it remains connected, especially when usage is light. What all of this means is that there is no data cap - we don't care about how many bytes you send through the satellite, only how long the satellite must spend handling your traffic.

This means that users with larger, higher-speed terminals (see the above point) able to transfer the same amount of data in a shorter period of time will pay less for the same amount of data transferred, as they will consume less beam time in doing so. Because beam time is the network's most important resource, and is the limiting factor in terms of network performance, we believe that charging for service in terms of the actual resource - beam time - being consumed is the most fair model for service pricing.

FemtoStar is a midband Mobile Satellite Service network, designed for speeds in line with other midband Mobile Satellite Service offerings. Here, the term "midband" refers to the level of bandwidth between narrowband services, designed to provide a low-speed connection to small, usually IoT/embedded terminals, and broadband services, designed to provide a high-speed connection to large, expensive, fixed terminals.

While this middle category of service may be unfamiliar to those more used to terrestrial services, it's common in the in Mobile Satellite Service landscape, and is what's offered by services such as Inmarsat BGAN, Iridium Certus, or Thuraya IP. In these services, as in FemtoStar, designing for this middle category means that users can expect performance much better than a narrowband system, while still having a portable terminal much smaller than those needed for broadband systems. Like the aforementioned MSS options, a typical FemtoStar terminal should provide in the mid-hundreds of kbps, using a terminal roughly the size of a tablet or small laptop.

Of course, FemtoStar's design still allows for flexibility on the size and speed of terminals - users should be able to choose their own balance between speed, cost, and portability. As such, depending on the size of the terminal, FemtoStar should be able to accomodate larger terminals in the megabits-per-second range, or smaller terminals with reduced (if still better than typical narrowband offerings) speeds in a pocket-sized form factor.

No, at least not by any usual definition of the term. While they are a digital system used to pay for service, and while they do make use of cryptographic signatures for security, FemtoStar Credit Tokens are not transacted on a blockchain, cannot be mined, and are not intended for use as anything other than payment for FemtoStar service. While third-party users are free to buy and sell Credit Tokens at any price they are able to, their value in FemtoStar service is fixed.

Once our network is operational, you will be able to purchase FemtoStar tokens from FemtoStar via a retail token sales portal, from a third-party reseller, in bulk from FemtoStar via a wholesale agreement, or from anyone else willing to sell them to you. While the FemtoStar Project is capable of pre-issuing tokens that will be usable once the network is operational, we do not currently offer pre-issued retail tokens to the general public, due to the inherent risk to consumers of purchasing a service before it is available. If you are interested in working with us to purchase wholesale tokens, for resale as a token reseller or for a large deployment of FemtoStar hardware as an enterprise user, please contact us.

Starlink is a low-earth-orbit communications constellation developed by SpaceX. While we have a tremendous amount of respect for the engineering accomplishments of the Starlink network, its goals and those of FemtoStar are almost entirely separate. While both intend to provide satellite communications service using low-earth orbit constellations, Starlink is designed to provide consumer broadband services to large, fixed terminals (in the satellite industry, this is known as Fixed Satellite Service). FemtoStar, on the other hand, is designed for midband services to small and medium, portable or in-motion terminals (also known as Mobile Satellite Service).

While the Starlink network is large, its architecture is traditional - it is designed to connect users to official ground stations providing official services. While there has been talk of limited use of Starlink for point-to-point connectivity, such as for high-speed securities trading, SpaceX holds complete control over use of this feature, and it is not a part of their consumer-facing services, nor is it known to be possible with their consumer hardware. FemtoStar's open-infrastructure architecture ensures an inherently net-neutral network, wherein all hardware is usable as a ground station, and even our own services are simply one of many a satellite is able to connect users to.

Starlink terminals are uniquely identified on the network, and can be easily geolocated by the network (whether they report their GPS location is currently unknown, but the network is certainly able to geolocate them accurately, as they are disallowed from accessing the network outside of the small region, or "cell", where their user's address is registered). Starlink users are required to provide a substantial amount of personal information in order to purchase service. Payments are handled on ground infrastructure, based on user accounts. FemtoStar does not require any user account whatsoever, is not restricted to use in a small cell, and handles payments on the satellite itself using FemtoStar Credit Tokens.

Blockstream is a cryptocurrency company which offers a service named Blockstream Satellite. Othernet is a company which broadcasts data, primarily news and other text content, via satellite.

Blockstream Satellite broadcasts the Bitcoin blockchain, one-way, over six geostationary broadcasting satellites, and offers an API to transmit your own short pieces of data over the network, with payment in Bitcoin. While Blockstream does allow for remote access to the Bitcoin blockchain, it is a one-way system - it cannot be used for two-way communications, or to make online cryptocurrency transactions, unless you already have an internet connection and can connect to its API.

Othernet provides one-way, broadcast data service via two geostationary satellites. This data typically consists of news, Wikipedia articles, and other low-data-rate content which can be delivered one-way.

Both of these companies purchase time on existing geostationary broadcasting satellites, of the type typically used for consumer satellite television. These services do not support, nor is the hardware provided for them capable of, any form of uplink from the user terminal. While both services are useful as tools for broadcast data distribution, they are one-way, Broadcasting Satellite Service systems, distinct from two-way communications systems in the Fixed Satellite Service (such as Starlink) and Mobile Satellite Service (such as FemtoStar).

We're big fans of a number of the terrestrial privacy-respecting communications projects currently in development - in fact, FemtoStar began as a terrestrial network, named Private Mobile Data Protocol (PMDP).

The fundamental issue of terrestrial networks is the amount of hardware necessary to provide adequate coverage. It has taken decades of development, thousands of licenses to thousands of companies in hundreds of countries, hundreds of billions of dollars at least, and more than 7 million cell towers to build mainstream cellular networks out to their current coverage, and even with this it's likely you still sometimes have problems getting cellular service. We began with the assumption that a terrestrial network would be the only practical solution, and extensively tested PMDP hardware in real-world urban and suburban environments. Eventually, even we - the developers of the technology - were forced to admit that it was impractical without an impractically dense network, even for a small, urban implementation - letalone regional or global coverage.

As a thought experiment in community-run terrestrial networks, next time you leave home, ask yourself if you are ever more than 1 kilometer (3200 feet) away from somewhere a mesh node or base station in a community-run terrestrial network could be installed without being removed, stolen, or tampered with, and if anyone nearby would be willing to pay for, install, and maintain such a device. We tried this, with real hardware, in a real city, in 2019, and came to the conclusion that that, in contrast to being an easier solution, it was likely outright impossible in most circumstances.

Where such networks can exist, they genuinely do have some advantages over satellite-based networks - however, in most places, it is simply not realistic to build them. We found this out the hard way. It's also worth noting that FemtoStar can coexist with these networks symbiotically - where these networks can be built, given that this is likely to occur in clusters of nodes or base stations (such as in a city center) separated by a substantial distance, we believe FemtoStar could be extremely useful to link these sections together into larger, more resillient networks.

See the above point. While mesh networks are able to partially solve the problem of base station range by allowing every user device to extend coverage, this still does not allow for coverage where there are no nodes. The same thought experiment applies - are you always within a kilometer of someone else who might have a node in the mesh? If you have your own node in the mesh, is there ever another node nearby for it to mesh with? If not, a mesh network may not be practical in your situation. Even where mesh networks are practical, FemtoStar could still be used to interconnect regions where the mesh is available, even when they are separated by large regions with no nodes.

Not to nearly the same degree. While the distance to the satellite does add some amount of latency due to the time taken for the signal to reach the satellite, the round-trip propagation time to a low-earth orbit satellite is a handful of milliseconds, not the hundreds of milliseconds familiar to users of geostationary satellite networks. Ping time on FemtoStar should be less than a tenth of that which a geostationary satellite user would experience, if even that.

In contrast to the vast majority of small satellites, FemtoStar plans to include electric propulsion onboard our satellites, allowing them to be repositioned as needed and cleanly deorbited at end-of-life. The FemtoStar Project is working closely with Applied Ion Systems, a leading developer of open-hardware smallsat propulsion hardware, to develop a specialized implementation of their technology for use onboard the FemtoStar space vehicle. Even in the event of a thruster failure, the solar panel can be positioned to drastically increase atmospheric drag on the satellite, rapidly increasing orbital decay and deorbiting the satellite.

The network can theoretically work with as little as a single satellite, however of course this configuration does not allow for continuous coverage. Practical constellation layouts begin at around 48 satellites (and include the layout shown on our homepage. We have also considered the possibility of starting with a larger constellation of up to 96 satellites, however we believe the most reasonable approach would be to begin with the minimum practical number of satellites (likely 48) and then scale up the constellation with new satellites as needed.

The FemtoStar network provides multiple levels of protection against failure of spacecraft, and against failure of the network due to failure of a spacecraft, resulting in a resilient network able to mitigate and work around hardware failures onboard satellites. Each satellite incorporates a degree of redundancy previously seen only on far larger satellites, and is designed with longevity in mind. The network as a whole also protects against network-wide failure as a result of the failure of a single satellite - most regions, especially those with a latitude near the inclination of the satellites such as North America Europe, and Oceania, and much of Asia and South America - are covered redundantly, and even elsewhere, the "gap" caused when the only satellite visible to a user has failed is short - lasting only minutes or less before working satellites come into view.

For most users, a satellite failure would likely be noticeable only as a decrease in the network's coverage angle, while for those in the aforementioned near-inclination regions, it might not be noticeable at all. Finally, FemtoStar would be able to rapidly and inexpensively replenish its network with new satellites, either newly-launched or simply moved into place if already available in a storage orbit.

FemtoStar is not purely a "privacy" system - we believe it to be competitive with other mobile satellite options, and in all likelihood there will be plenty of FemtoStar users who aren't even aware of, much less interested in, its privacy features. We also believe there will be a number of FemtoStar terminals installed as a part of machine-to-machine data installations, as backup connections for enterprise networks, or as backhaul to community-run terrestrial networks. A user using it for privacy reasons is indistinguishable from any of these users.

Additionally, by this rationale, any privacy-respecting product, service, or system is bad for your privacy, as its use demonstrates that you are looking for privacy. Even if your threat model truly does require that you obscure even the fact that someone is using a system that could be used for privacy-respecting communications, FemtoStar still does substantially better than just about any other privacy-respecting communications network. For one thing, it uses a substantially more directional antenna than any terrestrial mobile, which means its transmitted signal is very weak in any direction but that of the satellite.

Its connection to the satellite is also is encrypted, and even to the satellite, it does not contain a location, terminal identifier, user account, or any other identifying details. The terminal never transmits when it has no session open with the satellite, and, unlike mesh network nodes, it cannot be made to transmit by the traffic of another user unless the terminal's owner has chosen to operate their own service over the network.

In theory, to some extent, but in practice, not meaningfully. In contrast to traditional communications satellites, a FemtoStar satellite, at least for transmit, does not have a consistent beam pattern. Instead, electronic beamforming is used to point each of only a handful of beams, rapidly switching beam patterns as the satellite jumps between active sessions. The footprints within which these beams are usable are hundreds of kilometers across, even at their narrowest, and more than 2000 kilometers long. In addition, knowing where "you" are, as opposed to just knowing the rough area in which one of the network's users is located, requires knowing who you are. As such, the satellite could determine that an anonymous session is within, for example, northern Europe, western North America, or eastern Asia, but not that it is in a particular country or city, and certainly not who that session belongs to.

We do not feel that we can promise that there is any two-way wireless communications system where it is truly impossible for an adversary to locate a transmitter given enough time to search for it on the ground. In particular, it is extremely difficult to prevent just about any transmitter from being detectable by a high-gain antenna at short range, no matter how directional or low-power the transmitter may be. However, we also believe that such a search would need to begin relatively close to any terminal it wanted to have a chance of finding, and that it would likely be complicated by the presence of more than one FemtoStar terminal in an area.

Additionally, there's the question of why finding terminals would be worthwhile to an attacker to begin with. Given that such an attack would almost certainly involve the rather labor-intensive task of traveling around an area of interest with a vehicle full of equipment looking for terminals that you cannot identify and cannot monitor the activity of, while also being unable to tell the difference between two intermittently-used terminals and one terminal which has moved, we do feel we can say that this attack is unlikely to fit into many threat models.

A FemtoStar terminal can even be used as a receive-only device if this is acceptable for the user's use case - in this configuration, it would likely be nearly impossible to geolocate, even with this sort of attack.

In short, we don't believe any transmitting device is truly geolocation-proof, but we do believe that geolocation of users can be made impractical for to perform at a large scale, and that its value to an attacker can be substantially diminished. On top of this, we do feel we can safely say that FemtoStar is substantially more geolocation-resistant than any currently-available two-way wireless communications system, and that it is likely that its geolocation-resistance could only be matched or exceeded by another satellite-based system including most or all of the same geolocation-resistance features.

The FemtoStar architecture does not require that you trust the FemtoStar Project, even to begin with. Because the user is not required to trust the FemtoStar network, in order for the FemtoStar Project, or or an entity who had taken it over, to meaningfully compromise the security of FemtoStar users, many core design elements of the network would need to be changed, necessitating, at minimum, a firmware update to user terminals to accomodate substantial protocol changes. A new update published without source code would be immediately suspicious, as would a new update where the newly-released source code disabled privacy features.

See the above point. Even if a malicious government were to take over the FemtoStar Project and attempt to surveil its users, they would be incapable of doing so without making changes that would be immediately obvious to users, and to our own developers in other countries. Additionally FemtoStar Inc. in Canada is only one part of the overarching FemtoStar Project - we have developers all over the world.

While we would never claim that it is impossible that a FemtoStar satellite could be compromised, either remotely or through physical attack, we believe the likelihood of this to be low for a number of reasons.

The most important point here is that FemtoStar satellites are not especially useful targets to an attacker. Due to not being a trusted part of the network, even if they themselves are fully compromised, they cannot be used to compromise FemtoStar users, nor would they be much use as part of a botnet, nor would they provide an attacker with any additional utility in their intended purpose (communications) than is available officially.

With regards to compromising the satellites from the ground, the satellite's onboard software is subject to intense scrutiny, including through formal proofs, makes extensive use of sandboxing, and, given the relative simplicity of the FemtoStar protocol, presents a small attack surface.

In terms of physical security, while FemtoStar's placement of its infrastructure in orbit certainly grants it a degree of inaccessibility compared to terrestrial infrastructure, there are of course spacecraft which could conceivably reach a FemtoStar satellite, and could hypothetically either tamper with or replace it. However, tampering would require physical capture and substantial disassembly of the satellite, which is detectable and would result in the deletion of onboard keys, resulting in a tampered-with satellite being easily detectable from the ground (even if new software attempted to obscure this tampering), while a replacement satellite would lack the cryptographic keys of the satellite it replaced entirely.

An attacker could opt to attempt to disable, capture, or destroy a satellite altogether - after all, if you want to assume that truly no adversary is off the table, you could choose to consider even the use of anti-satellite weapons. However, an attacker trying to make the network truly unusable would need to destroy or disable not just one satellite, but the entire constellation, and any replacement satellites, and to do so in a way which obscured their involvement, a daunting task even for the largest possible adversaries. This type of attack is also immediately obvious (especially if the satellite is physically destroyed, resulting in the generation of orbital debris), and even this still does not result in an actual compromise (geolocation, identification, etc.) of FemtoStar users.