Interesting that it seems like the application method is to melt the glue:
> To test its adhesive strength, researchers first glued two untreated polytetrafluoroethylene (PTFE) plates by sandwiching molten CyclicFP-fmoc between them and letting it cool at room temperature for 10 min.
Also notable that the glue substance is reusable:
> Remarkably, a simple ethanol wash completely stripped CyclicFP-fmoc from the target PTFE plates, leaving no trace behind. The recovered adhesive proved repeatedly reusable, reliably maintaining its adhesive strength of ~1.2 ± 0.1 MPa across multiple cycles.
Perhaps hot glue guns are going to get an update ;)
For anybody not getting the reference, standard glue gun glue is obviously applied freshly melted and hot, and it is dissolved/debonded cleanly with isopropyl alcohol.
There are safety regulations that require things roughly like, "to prevent harm to planes in the air and people on the ground, either control where your satellite re-enters so or make your satellite entirely out of components that are almost certain to burn up on re-entry".
As far as I can tell, there is no environmental regulation of how many kilograms of aluminum, silicon, etc. being added to the Earth's atmosphere when a Starlink burns up during re-entry.
Cool idea. Given that it transferred ~29 mb when loading, is it safe to assume that the actual page is doing some of the processing? Is the front-end just doing the HNSW or is it doing the mapping of stories or headlines into vectors, or am I totally off base?
Front-end downstream of clicking on a card doesn't seem to work correctly on every reload... but it works sometimes.
they're definitely on the roadmap but not in the alpha yet. The syntax like CREATE CONSTRAINT ON (n:Person) ASSERT n.email IS UNIQUE is designed to work, and we've got the error handling infrastructure in place, but the actual enforcement logic is planned for v0.2.0 and beyond. Same goes for relationship constraints - the foundation's there with schema validation, but the complex constraint types are coming in future versions.
Indices are similar - we've got the query planner logic ready to use them, and label indexing is partially implemented as a foundation. Property indexes are definitely planned, with basic support in v0.2.0 and composite indexes following in v0.4.0. The current alpha focuses on getting the core Cypher operations (CREATE/MATCH) solid before layering on the optimization features.
The roadmap shows:
v0.2.0 (Q1 2026): Property indexes and basic constraints
v0.4.0 (Q3 2026): Advanced indexing (composite, spatial)
v1.0.0 (2027): Full constraint support
For now, you can enforce constraints at the application level or use raw SQLite constraints on the backing tables if you need that functionality immediately. The alpha is really about proving the core graph operations work end-to-end before adding the enterprise features.
Seems like a source that one should not generally take seriously (Tipranks) being syndicated by a source associated with an important name (Nasdaq) as part of a larger wave of articles about how some "pact", "treaty", or "contract" ended on a specific day.
Having done a little more digging, I could find lots and lots of pieces about this topic, but I could not even one coming from a recognizable journalistic source. (Far from the top of search results was a piece that seemed to have some value: it noted the wave of coverage of the purported end of this pact despite the fact that no such pact existed. It also identified a possible connection between pushing this story, which makes the dollar sound endangered, and attempting to promote cryptocurrency.)
Lots of HN commenters taking this at face value. To me, the overall situation looks like an object lesson in basic critical media literacy.
My understanding of the state of the art of inter-satellite optical links is that they have only been used between satellites that are basically in the same orbital plane and in more or less the same orbit. That is, the angle from one satellite to the other changes very very slowly, so that the optics don't have to do much tracking -- and consequently satellites can only form an optical link with other satellites that are ahead or behind themselves in ~ the same orbit.
Cross-plane optical links would have a trickier tracking problem.
While there's no explicit mention of same-plane vs cross-plane optical links, I assume that the first time people have a public cross-plane optical link, they will make a big deal out of it. :)
The article also mentions that SpaceX would need to do further study before using laser links between satellites and ground stations-- this kind of optical link would require both more angular tracking and probably atmospheric correction as well.
> “Another really fun fact is that we held a link all the way down to 122 kilometers while we were de-orbiting a satellite,” he said. “And we were able to downstream the video.”
> For the future, SpaceX plans on expanding its laser system so that it can be ported and installed on third-party satellites. The company has also explored beaming the satellite lasers directly to terminals on the Earth’s surface to deliver data.
The lasers aren't used for ground-to-satellite comms. While they refer to some of them maintaining a link through the atmosphere, the lasers are intended for satellite-to-satellite communication way above the atmosphere.
There are some wavelengths that maintain decent signal quality through cloud cover, and even rainstorms. I cannot find the paper right now, but iirc Tightbeam (formerly from the Google sharks with lasers team, now spun out as Aalyria), demonstrated space to ground comms in adverse weather with negligible packet loss and something like 40% reduced bandwidth.
The customer terminals will likely never connect through lasers (because a laser can only point in one direction at a time), but moving the ground station uplink to a laser link sounds very beneficial.
It would fall back to radio and/or other connections. The laser connection would probably be sold at a discount rate due to the variable level of service.
Take a look at the slides from the presentation, I think the geometry clearly shows cross-plane links in the mesh. Having worked on these types of systems, I've had more difficulty with the lookahead angles (rx from where the target was, tx to where it will be due to speed of light) than the tracking -- fine tracking performance was required for all modes, and it largely became a GNC and acquisition time issue (since they're ephemeral) for the cross-plane links.
In general, how is the initial alignment performed?
Is there rough pointing, followed by some rastering, until the sensor gets a hit? Maybe with some slight beam widening first? My assumption is that you would want exactly one laser, one sensor module, and probably a fixed lens on each? Is the sensor something like a 2x2 array, or pie with three pieces, to allow alignment? Or is it one big sensor that uses perturb and observe type approach to find the middle?
Also, is there anything special about the wavelengths selected? Are the lasers fit to one of the Fraunhofer lines? 760nm seems like a good choice?
Alas there is no 'in general'. Acquisition is often the secret sauce due to, among other challenges, the extremely tight alignment requirement -- thermal shifts, satellite wobbling, etc, are all critical to manage.
On wavelengths, if you're trying to hit 100gbit+, you're probably having to use coherent optics, and there aren't many technology options or wavelengths on the market.
You got it exactly right! I worked on a simulation model of the complete optical setup of a laser terminal with movable mirrors and all including the fricking servo motors and a simple orbital model for the relative satellite positions. Plus an interface to drop in the actual acquisition and tracking code used on the embedded control system. All of that just to be able to do reasonably realistic simulations for verification and tuning of the secret sauce.
The "routing in the mesh" slide? Definitely given where the satellites are in that picture some of the links would have to be cross-plane, it's just the whole thing looked so messy (even with it being geo-referenced on a globe) that I didn't know whether to consider it a "real routing example" vs a "notional routing example that we overlaid on the globe".
Sounds very cool that cross-plane links are doable, even if they have predictable complications compared to in-plane.
I would have thought that someone would make a big deal (have a press release, e.g.) out of successfully establishing cross-plane links, but maybe it just doesn't seem that impressive to people who already have good enough precise predictive ephemerides or satellite states to make those links in the first place.
Tracking is an issue, but doppler can also be a thing. At orbital speed (actually up to 2x orbital speeds) the doppler effect between two satellites can change the frequency enough to cause interference. Moving a scope to track a moving target is one problem, allowing the algorithms to adapt at the frequency shifts on the fly another.
Indeed Iridium had to deal with the same thing (or I guess, didn’t):
“ Cross-seam inter-satellite link hand-offs would have to happen very rapidly and cope with large Doppler shifts; therefore, Iridium supports inter-satellite links only between satellites orbiting in the same direction.”
There were some experiments with communicating over Iridium to small cube-like sats back in the day, but we couldn't make the system on a chip beefy enough to do the Doppler shift calculations on the fly and survive a launch; it was close though. I think its possible to do now.
In the context of the full article (https://en.wikipedia.org/wiki/Iridium_satellite_constellatio...), it's clear they're talking about the polar orbits used by the Iridium constellation, which have "seams" around the Atlantic and the Pacific as the "first" set of satellites passing north-to-south overlap with the "last" set of satellites coming back south-to-north on the other side of their orbits. So of the 6 orbital planes used by the Iridium satellites, each plane covers 1/12th of the globe for each "half" of its over-the-poles orbit. So there are two "seams" where handoff is not supported, one off the eastern seaboard and one roughly over Japan.
Ah I didn't realize they have all of their stats in polar orbits, that's interesting. Starlink is mostly equatorial afaik, the higher latitudes aren't very well covered.
The Iridium satellites are in what you might call "parallel" orbits, if you stretch the meaning of the word a little bit.
The wikipedia link above explains it well:
"""
Orbital velocity of the satellites is approximately 27,000 km/h (17,000 mph). Satellites communicate with neighboring satellites via Ka band inter-satellite links. Each satellite can have four inter-satellite links: one each to neighbors fore and aft in the same orbital plane, and one each to satellites in neighboring planes to either side. The satellites orbit from pole to same pole with an orbital period of roughly 100 minutes.[8] This design means that there is excellent satellite visibility and service coverage especially at the North and South poles. The over-the-pole orbital design produces "seams" where satellites in counter-rotating planes next to one another are traveling in opposite directions. Cross-seam inter-satellite link hand-offs would have to happen very rapidly and cope with large Doppler shifts; therefore, Iridium supports inter-satellite links only between satellites orbiting in the same direction.
"""
The 'seams' have interesting implications for latency when I was working on Global Data Broadcast.
Doppler is not a big problem with lasers because the carrier frequency is so much higher than RF that it doesn't matter; it's bang-bang AM modulated.
I'm assuming two things: That something like Manchester coding is being used so that some clock skew is tolerable, and that the laser carrier is not in fact being frequency or phase modulated. Last I checked FM and PM of optical frequencies was not yet practical outside of laboratories, but I'm happy to be corrected.
Nah, I once did a job for a guy and they did LEO-GEO distances alright iirc and LEO-Earth in the mid-end 2000s, which has to deal with some pretty high angular velocities, if not as potentially high as LEO-LEO when they don't happen to be relatively nicely aligned. (In case that sounds strange, the guy was one of the two owners of a small, very specialized company that in turn was subcontracted by a rather bigger company. These laser terminals were quite the beasts and not really cheap.)
Right. The Iridium network had communication between satellites in different orbital planes passing each other but that was a pretty unusual capability.
They do have counter rotating planes though, so there are places where two satellite tracks next to each other moving in opposite directions, and these pairs of satellites cannot use the cross plane communication mode.
Additionally, their inter satellite links use regular Ka band radio.
It doesn’t get into it too much on pages 14 and 15, but it indeed suggests that they probably exclusively use the “intra-orbital” links closer to the poles to get data to a satellite where the inter-orbital links are more practical.
I believe Iridium had way more downlinks than they used to pre-bankruptcy. I guess volume constraints were less of an issue, so ok to hop around more in space.
Apparently it only happens above/below 68 degrees latitude, so the next satellite with a working inter-orbital-plane connection is at most one hop ahead or behind.
I'll assume there is a lot of double/triple (or higher) accounting going on here as data is sent through multiple relay hops to get the intended target.
My biggest beef with JSX is that what I might call the "most natural way" and certainly the "most concise way" of writing certain somewhat-complex structures in JSX often ends up being a huge mess. E.g. an element is some JSX elements with some code embedded, and the embedded code is returning some other JSX elements that have yet more code embedded in them, and the easiest refactoring to make the whole thing less gross is extracting functions that don't really deserve a name of their own.
reply